Removed Areas > C / C++

Managing Large code with Object Oriented Programming

(1/2) > >>

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).

Navigation

[0] Message Index

[#] Next page