Take the 2-minute tour ×

I'm kind of a beginner to Java and OOP and I didn't quite get the whole concept of seeing a real world problem and translating it to classes and code.

For example, I was reading a book on UML and at the beginning the author takes the example of a tic tac toe game and says: "In this example, it's natural to see three classes: Board, Player and Position." Then, he creates the methods in each class and explains how they relate. What I can't understand is how he thought all this.

So, where should I start to learn how to see a real world problem and then "translate" it into code?


migration rejected from stackoverflow.com Sep 29 '14 at 6:49


closed as too broad by gnat, MichaelT, GlenH7, amon, Kilian Foth Sep 29 '14 at 6:49


If the author really wrote "it's natural to see three classes", I'd say that's a bad book to learn from. These things are "natural" only after you have really grokked them. Even then, "natural" is a poor word to describe it. –  Mauricio Scheffer Mar 18 '11 at 18:41
It is natural if you have experience and understand how OOP works. I believe you can get there with practise and any good book. –  Johan Sjöberg Mar 18 '11 at 18:42
Natural is usually pretentious double-speak for 'my way is right' :) –  spinning_plate Mar 18 '11 at 18:54
Moreover: saying something is "natural" doesn't explain anything to those that don't consider it natural (i.e the readers). Not to mention that many people consider functional programming more "natural" than OOP. –  Mauricio Scheffer Mar 18 '11 at 19:21
I'd say it's natural to see two classes: board and gaminig pieces. Positions are not natural classes. Players are typically outside the scope and therefore not natural either. –  user281377 Mar 19 '11 at 18:34

1 Answer 1

up vote 3 down vote accepted

Not all problems have to be solved in an OOP fashion.

Real world programs are mash up of different styles.

You will generally find that code goes through a few states:

(1) You start with a clean solution (possibly). (2) It goes live and bugs are found. (3) Bugs are fixed, code becomes more stable. (4) New features are added, the "clean-ness" starts to drop. (5) After many cycles, the initial clean structure becomes a complex mess. (6) Sometimes refactoring occurs. (7) Code is either re-written OR slowly slimed down and cleaned up.

During the clean up OOP may be used to achieve good code - reuse.

