Managing Large code with Object Oriented Programming

[icekin]

I've taken a course this semester at my university in Object Oriented Programming. I was a decent C and C++ procedural programmer and didn't think that object oriented programming would be that difficult. How wrong I was.

I was unable to complete the course assignment. Or rather, I completed it and spent even longer on debugging it to find out why it crashed. In the end, I was unable to locate the logical errors, but submitted the assignment anyway. Eager to get the project out of the way, I had started writing code fast, but without a good design.

What I realized was that while I understood the syntax of the language, I was not taught any code design and management skills (don't know if I should blame my Uni or myself there), which eventually led to my downfall. I rewrote large sections of the code 3 times, wasting time as the design was not completely object oriented (e.g. other classes could control the behavior of some classes, rather than each class being able to control its own behaviour and attributes). Soon, I found myself facing thousands of lines of code, over a dozen classes and over 50 to 60 different functions (some with very similar names, but in different classes!). Couldn't even figure out where the logical errors where anymore and just reading the code became hard.

Conclusion:

What I would like to learn now is how to organize a project like this better. I am set to graduate soon and my first job ironically enough is going to be in writing software. I don't want to repeat my mistakes above.

I want to ideally be able to make the best possible design (with execution efficiency and future maintanence) once, write the code once, debug once and be done with it. I am willing to read up extra books to educate myself on this design issue.

So, kind fellow DC members, please throw some tips. How do you organize your large code? I would also like to know how much of a big deal Object Oriented Programming is. After this assignment, I've started disliking it as I wasted too much time trying to contain everything inside classes, eliminate friend functions and so on. This even led to longer lines of code and seems counter productive to me.

[mouser]

You are well on your way to mastering it -- you've made the first few steps by coming to grips with the fact that knowing the syntax of a programming language is just the very initial step.

The most important thing is to do what you are doing: PRACTICE.

Only by writing code are you really going to get comfortable and efficient with OOP concepts.  The good news is that OOP is very well suited to large projects so you are on a good path.  You just need to get more comfortable with the concepts and practice.

As for books, there are a couple: Code Complete might be good (see this thread)

Maybe try "http://Thinking in C++" or another C++ book that stresses OOP concepts.

[hollowlife1987]

I personally found this one to be a good book for explaining many different design patterns, but I wouldn't touch the book unless you understand basic concepts of OO

[Gothi[c]]

There are literally boatloads of examples, and very thick books have been written on the subject... a good way i found to learn OO design is to use a good OO library in one of your applications, and get familiar with it's class design, and then eventually when you are comfortable with it, look into the code for gems.

A good OO library would be one that makes use of all the C++ features when appropriate. Makes use of namespaces, templates (but definitively does NOT over-use templates, which leads to nightmare scenarios), sub-classing, etc...

I'd say the Irrlicht library is a pretty good and simple example to learn from.

I'd also recommend documenting your code with doxygen from the very start (document as you create your classes and functions, not after you're done). I have found that keeping a browser open with a doxygen api documentation page of my own code helps me organize my mind, and it provides a nice overview of what's in your app. It can also create call graphs from your code.

[icekin]

Thanks for the tips so far, I've used Thinking with C++, its what our course recommended as a reference as well. Embarrassingly, I only learnt about 3 weeks ago that there was a standard for documenting code and even naming classes and functions. Till then, I assumed that clear descriptive names would suffice, which is what I've always used in C. But then I've never written a software for use by anyone besides myself.

This is the standard I've used for this assignment, I'm not sure if that's same all over the industry.

I was also taught some UML at the end and was wondering if coders in industry actually start with a UML diagram and proceed to code? During this assignment, I started writing code with the main and then worked my way downwards. But then, I used to also work upwards and started from the lowest level child classes at the same time, while writing some of the in between functions in various files, which were all open at the same time. Later, someone told me about top down and bottom up approaches, but I never quite understood it. Are these coding methods purely concepts or can they be strictly adhered to in reality? Meaning, would a top down approach be strictly top down (i.e. create a file, write all the functions in it and don't come back to it until compile time).

[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  . 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 ( ) - 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."

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.