OOO and OOAD

OOO = Object Oriented Organization (of code).
OOAD = Object Oriented Analysis and Design (of a system).

Code rushes through my head when I hear people talking about various software projects.. that is the wrong way to think.. if you can think DESIGN before you think CODE that means you are a top class computer engineer (or programmer).

But professional design is a tediuous and often time consuming activity which is as important as it is difficult to do well!

Most small projects or dedicated systems, in my experience, are designed on the basis of 'object oriented organization' rather than full blown OOAD (which involves higher level elements such as Design Patterns).
The system is just represented as a set of interacting classes or objects.
This can be very effective, reducing design times as well as making sure most of the good design features are present in the result. But this requires an implicit understanding of what is good OO and what is bad OO!

If you find yourself stringing together classes like a garland one after the other then you are surely doing something mad.. and trust me.. pretty soon that garland is going to start stinking!

The basis of good OO design is how to keep the interfaces of the classes clean and less prone to change and the number of classes themselves to as few (and thus efficient use of code) as possible. Thus it becomes VERY VERY VERY IMPORTANT to understand and keep in your mind AT ALL TIMES the concepts of cohesion and coupling whether you are doing OOO (Object Oriented Organization of your code) or full fledged OOAD.

For those who don't know about Cohesion (Coh.) and Coupling (Cup.):
Coh. means how well organised the code is within a class... how well the code of the class works together to fulfill the functionality of the class. If a class is really bulky and requires access to external code then we say that Coh. is low.

Cup. means the number of connections a class has with other classes.

Usually the best design practice is to INCREASE COHESION and DECREASE COUPLING. This ensures classes remain as stand-alone and re-usable as possible as well as decreasing the 'stringing' effect of dealing with a highly connected set of classes.

The common trick for reducing Coupling is, if you find that two classes have a lot of connections between them, try and merge the two classes together or try and shift the functionality from one class to the other (you can even try merging the functionality from both classes into a third class!).
To reduce cohesion you need to concentrate on the first level analysis of the problem (high level requirements). Often a re-analysis of the problem can lead to a more efficient Class/Object based Design.