We don't object model to write object-oriented code, we write object-oriented code because we object model

A title taken from Jill Nicola et al.'s Streamlined Object Modeling.

One of my concerns about Java and .NET Framework alike is that, as more and more people use O-O platforms, it is more and more frequent that the paradigm is badly misused. The point I am trying to make is: if you don't create an object model to represent your business problem, then there is no point in getting tangled with [insert-your-favourite-O-O-language-here]'s inheritance, polimorphism, etc.

So I decided to prepare a small presentation for potential customers with some tips and tricks for identifying objects taken directly from the book. From time to time the book takes a patronizing air, but it is bareable, and it is full of sharp and usable advice. One example:

The Context Principle

A context of participation exists whenever a person or organization undertakes actions that are tracked and recorded. Actions that require different permissions or information from the person or organization belong in different contexts.

The Role Principle

For each context an entity participates in, create a separate role object. Put the information and permissions needed for that context into the role.

In other words, to the ancient problem of Jane Doe who is at times customer, at times employee, at times manager, create the person class and the customer, employee and manager role classes. Later you will define a composition between a person and the set of roles she has. Don't invent the wheel, better follow these modeling patterns. The book not only gives you the somewhat abstract principles but explain them with simple but real world examples. Definitively worth reading for someone trying to create an object oriented system.