How to identify what is not a Class?

Answer 1

The rules are simple.

• Everything is an object.

• All objects belong to classes.

In rare (very rare circumstances) you have some specialized class/object confusion.

1. A "library" of all static methods. This is an implementation choice, and no user can see this.

2. A Singleton where there can only be one object of the given class. This does happen sometimes.

Answer 2

The only real answer is experience. However, some things fairly obviously (to me, anyway) cannot be modelled in your design. For example if the use case says:

"and then the parcel is put on the UPS van"

There is no need to model the van. You can make decisions of this kind by considering the system boundaries - you don't and can't control the van. However,

"we make a request to UPS for pickup"

might well result in a UPSPickup object.

Answer 3

In an OO language it is not a question of what to be made into a class, but rather 'what class does this data/functionality go into?'

Like other software architecture aspects there are rules, but ultimately it is an art that requires experience. There are lots of books on software design, but a simple reference is Coupling and Cohesion.

• Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.
• Coupling between modules/components is their degree of mutual interdependence; lower coupling is better.