Learning object oriented thinking [closed]

Answer 1

There are a blockade in my mind that disables me from seeing where I should use a class and where I should not.

When it comes down to it classes are a way to separate complex systems into simple parts that interact with each other. Try to create classes where otherwise you would be repeating yourself.

Right now the gauge was an Integer in the Plot class.

Does the gauge need to be a class? What would the advantage of turning it into a class be? These are the sort of things you always need to ask yourself.

1. Game Engines are difficult to design. The separation of such a vaguely defined requirements is a complex process, read here: article on game engines
2. Design is iterative and you'll refactor several times, don't be surprised by this.

Answer 2

There's an essay in the book "ThoughtWorks Anthology" by Jeff Bay: "Object Calisthenics" in which he gives a set of rules for designing OOP sofware:

1. Use only one level of indentation per method
2. Don't use the else keyword
3. Wrap all primitives and strings
4. Use only one dot per line
5. Don't abbreviate
6. Keep all entities small
7. Don't use any classes with more than two instance variables
8. Use first-class collections
9. Don't use any getters/setters/properties

On the first look it may look too strict to follow all these rules. Keep in mind that even trying to write some code that coplies them will make you better OOP designer.

Answer 3

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.

Answer 4

Head First Object-Oriented Analysis and Design

I love Head First Books because they are fun to read. They have exercises and puzzles to scratch your head. I've read this book and found it very good.

The book covers:

• Use OO principles (encapsulation and delegation)
• Open-Closed Principle (OCP)
• The Single Responsibility Principle (SRP)
• Design patterns, UML, Use cases etc.