OOP - How to choose a possible object candidate?

Question

I 'm concern about what techniques should I use to choose the right object in OOP

Is there any must-read book about OOP in terms of how to choose objects?

Best,

Answer 1

You probably mean "the right class", rather than "the right object". :-)

There are a few techniques, such as text analysis (a.k.a. underlining the nouns) and Class Responsibility Collaborator (CRC).

With "underlining the nouns", you basically start with a written, natural language (i.e. plain English) description of the problem you want to solve and underline the nouns. That gives you a list of candidate classes. You will need to perform several passes to refine it into a list of classes to implement.

For CRC, check out the Wikipedia.

I suggest The OPEN Toolbox of Techniques for full reference.

Hope it helps.

Answer 2

I am assuming that there is understanding of what is sctruct, type, class, set, state, alphabet, scalar and vector and relationship.

Object is a noun, method is a verb. Object members can represent identity, state or scalar value per field. Relationships between objects usually are represented with references, where references are members of objects. In cases, when relationships are complex, multidirectional, have arity greater than 2, represent some sort of grouping or containment, then relationships can be expressed as objects.

For other, broader technical reasons objects are most likely the only way to represent any form of information in OOP languages.

Answer 3

Just write something that gets the job done, even if it's ugly, then refactor continuously:

• eliminate duplicate code (don't repeat yourself)
• increase cohesion
• reduce coupling

But:

• don't over-engineer; keep it simple
• don't write stuff you ain't gonna need

It's not a precise recipe, just some general guidelines. Keep practicing.

P.S.

Code objects are not related to tangible real-life objects; they are just constructs that hold related information together.

Don't believe what the Java books/schools teach about objects; they're lying.

Answer 4

You should check out Domain-Driven Design, by Eric Evans. It provides very useful concepts in thinking about the objects in your model, what their function are in the domain, and how they could be organized to work together. It's not a cookbook, and probably not a beginner book - but then, I read it at different stages of my career, and every time I found something valuable in it...

Answer 5

I am adding a second answer due to demian's comment:

Sometimes the class is so obvious because it's tangible, but other times the concept of object it's to abstract like a db connector.

That is true. My preferred approach is to perform a behavioural analysis of the system (using use cases, for example), and then derive system operations. Once you have a stable list of system operations (such as PrintDocument, SaveDocument, SpellCheck, MergeMail, etc. for a word processor) you need to assign each of them to a class. If you have developed a list of candidate classes with some of the techniques that I mentioned earlier, you will be able to allocate some of the operations. But some will remain unallocated. These will signal the need of more abstract or unintuitive classes, which you will need to make up, using your good judgment.

The whole method is documented in a white paper at www.openmetis.com.