Removed Areas > C / C++

Managing Large code with Object Oriented Programming

<< < (2/2)

f0dder:
One important rule: always do some pondering, considering, and design before you start chunking out code. For anything but the most trivial projects, things won't go according to plan and will be rewritten several times during project lifetime, but having thought a bit about stuff beforehand helps you not get lost as easily, and adapt to changes better.

I didn't do much planning ahead with fSekrit :-[, since it seemed that it was going to be such a small and easy program. It was, but I'm now facing rather large rewrites in order to get full unicode support, because I didn't plan ahead (fixing all API calls and static buffers was easy-peasy, but there's a couple of classes that definitely aren't unicode-friendly).

The Design Patterns book by Gamma et al is a must, imho.

Scott Meyer's "effective C++" and "more effective C++" have some good tips on what to do and what not to do in C++, but it's more on a smaller scale. Still valuable, though.

I can't really recommend "Large-scale C++ software design", as it is outdated, dry, and repetitive. I wish somebody would do a 2008 version of it, since a lot has happened in the last ~12 years.

ChalkTrauma:
When I started working for Rational Software in 2000, the first thing they did was send me to a Object Oriented Analysis and Design course and it nearly killed me  :D. I like Mouser's point about practice, it is so true, you really learn by doing. Back when I took that course I was reading everything I could on the subject and it all became so academic. For me it all started to fall into place when I took the basic OOP methodology and applied it to small,manageble projects, with a very well defined problem domain, and after a while it became easier and easier to see what needed to be an object and how behaviors should be implemented, and when a logical section of code became too long I could feel myself wanting to break it up into manageable contained parts that could be reused. Once all that starts happening, the design comes much easier earlier in the project, because you start to see the problem and solution from an object oriented perspective. I also helps to design small functional units that can be easily tested, rather than a monolithic code base that is like a black box.   I also think Gothi[c] had a good point about looking at real working code bases with good OOP design. I learned a lot from the Ogre3D engine. Steve Streeting is very serious about the OO design of that engine and keeps it really clean and well commented.  Hopefully my ramblings had some helpful thoughts.. I can never tell when I had this much coffee  :-\..

nosh:
This isn't OOP related but I've been meaning to ask something similar - I'd written a somewhat lengthy 16-bit program, a chess game with a very basic UI which followed the rules of play but the PC side didn't really have a brain ( ;D ) - it would just make the first legal move - I wanted to enhance it and give it a basic brain a couple of years after I wrote it but realised I'd have to wade through most of the code again to actually get a grip on things & dumped it coz it was too painful to do that. It was well commented but the only way I could (maybe) have got up to speed fast was if I had done some kind of detailed flowcharting. Do any of you flowchart or do any kind of preliminary documentation before getting on with the syntax? How do you cope with getting back to really old code?

ChalkTrauma:
For really old code or inherited code written by someone else I usually run it through Doxygen to get a feel for what is where, but I have also done the flowcharting thing get a better handle on the logic too as well as adding some tracing to the code or even stepping though it in a debugger.

Eóin:
My advice, which repeats a lot of what was already said, is as follows.

Check out Effective C++ and More Effective C++, if you know the material already by skimming through then good, but if you don't then it is absolutely mandatory. To quote Matthew Wilson-

"These books are must-reads for any C++ practitioner and rightly so.
...
You won't get a job in more development teams if you've not read these two books, and for good reason."
--- End quote ---

Next you have to check out Beyond the C++ Standard Library: An Introduction to Boost. Boost is huge but this book covers to essential libraries you should be using in every project.

After that there are many many more good books on C++, but delve into some of the free online resources. Some that spring to mind; Boost, The C++ Source, STLSoft and More C++ Idioms.

Finally I would recommend Imperfect C++, written by the earlier mentioned Matthew Wilson it is very heavy going but also invaluable. Other than that I'll finish off by saying happy studies, with C++ you will never stop learning.

Navigation

[0] Message Index

[*] Previous page