enki said:
I had read that you should use classes to represent concepts. How does
this work and what kind of concepts should be reresented as classes.
That verbiage is a cheap way to inspire you to think in terms of objects. It
can mislead.
Some folks say "read your requirements, and pull out the important-sounding
nouns". So even hallow this "search for nouns" as a phase in designing.
So suppose I find the noun "Car". That sounds like a harmless, obvious
candidate for a class, right?
It depends on the application. I could be writing a simulator for a
wind-tunnel to find a good shape for a car. I could be writing the
controller for a car's engine. I could be writing the point-of-sale software
for a carwash.
In each case, the Car itself is nebulous. Wind-tunnel software needs to
model shapes whose actual car-ness is irrelevant. The car's engine's
controller has only one car object, so its attributes can safely disperse
thru the controller. Nobody should ever decouple the controller from the
engine and plug it into a different car with different attributes. And
carwash software needs to track a carwash _event_, from buying a ticket to
entering the carwash with the ticket.
Ultimately, we need objects that present clean useful interfaces, so their
client modules can use them in straightforward ways. So suppose a carwash
user buys a ticket at a gas pump, then types their ticket number into the
carwash user interface, requesting permission to drive in. That leads to
this:
usersNumber = getUserNumberFromUI()
ticket = database.getTicket(usersNumber)
if ( ticket and
ticket.day == today and
not ticket.isWashedYet() and
ticket.isCreditChecked() ) then
UIdisplay("PLEASE ENTER CARWASH")
ticket.isWashedYet(true)
return true
else
UIdisplay("WRONG NUMBER. TRY AGAIN")
return false
end
This "analysis" has not revealed a Car object yet, despite the fact that
cars are a critical component of every carwash, anywhere. It reveals the
Ticket is the determinant object, and its behavior changes with its state.
After a wash event, you can't drive around and use your ticket again.
Objects are bags of behavior. Partitioning that behavior among objects helps
us invent objects that are easy to use right and hard to use wrong. The
search for nouns will help, but ultimately behaviors drive design. After
putting related behaviors together into an object, _then_ you think of a
name for that object's concept.
