Question

I’m currently working on a small 2D game-engine in C++, but I am now facing a daemon – I suck at designing a ‘system of classes’ that actually works. There are a blockade in my mind that disables me from seeing where I should use a class and where I should not. I was reading an article about engine-design and it purposed to use a ‘State’ class to manage the state of different game entries (I was using an int).
It also suggested that all objects for the game (not io/video/sound etc) derive from either Renderable or NonRenderable classes. That’s smart. I already know that that was a smart way of doing it – I mean, every object in Java is of baseclass Object right? Smart, I know that! How come I didn’t do it that way? What do I have to read to really get into this mindset?

Another example. I’m taking this summer-course in Ruby (really simple) and we’re supposed to design a camping site. Simple! So, a camping is a collection of ‘plots’ that each have a electrical-gauge to measure how much power the guest has consumed. My design was three classes, one for a Camping – that in turn used arrays of Guest and Plot classes. My teacher suggested that I use more classes. WTF(!) was my first thought, where, what classes? Everything was a class in my opinion – until I realized, maybe the gauge should be a class to? Right now the gauge was an Integer in the Plot class.

I want to learn how to come up with a object oriented solutions to my problems – not just how to make the most obvious stuff into classes!

Tips/books/articles/blogs?

I’m two years into a collage degree in CS and have been programming as a hobby for many years! I’m ‘just’ stuck – and it’s preventing me from creating any larger piece of software!

Answer 1

My personal experience was learning Object Oriented Software Construction with Object Oriented Software Construction, 2nd Edition by Bertrand Meyer.

The book was invaluable to me at that time, and still remains the single book from which I’ve learnt most regarding OO programming and software construction in general.

Here are some of its strong points:

• In Part A: The issues, a very good definition of software quality.
• In Part B: The road to object orientation, a logical, step by step search for OO techniques in a way that makes the reader think the investigation is being done live, that is, as if there were still no known results. You’ll probably acquire the mindset you’re looking for from this part.
• In Part C: Object oriented techniques, the technical core of the book, you’ll make your knowledge solid and learn very useful techniques regarding Design by Contract, Inheritance, Genericity, etc.
• Part D: OO methodology: Applying the method well is a more practical approach on design, which I also find very useful. See for example How to find the classes (22), which you can find online.

After these parts, more advanced topics come, such as Concurrency (30) or Databases (31).

Since the book uses the Eiffel language (designed by the author), this will put you in the right mindset and teach you to think. It will be easy to apply these ideas to other, more or less OO, programming languages.