You do object oriented analysis of your problem domain. This results in a set of objects. Then you design a class hierarchy for your objects (base, child etc).

You do object oriented analysis of your problem domain. This results in a set of objects. Then you design a class hierarchy for your objects (base, child etc). Trick is to realize objects themselves do not accomplish project purpose, they just have behaviors. How you play these behaviors decides what the application finally does. I am surprised to see no one has mentioned the analysis part. To identify and abstract (like pulling oil well from well) "classes" of objects in your problem domain is the core proponent of OO programming. This is the basis for all data hiding and reuse. The OO design principles (not design patterns) tell you how to go about your class design.Check this link: http://www.objectmentor.com/resources/publishedArticles.html http://www.objectmentor.com/resources/publishedArticles.html Once you have completed all your classes, you will realize how easy (and natural) it is to script the actual business logic of your application - more or less like a movie: while all the actors have their identities, the "script" tells how they interact and decides the movie experience.