Classes as concepts.

[enki]

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.

[Victor Bazarov]

enki wrote:

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.

I think you're in a wrong newsgroup. Please try 'comp.object' or a good
OOD (Object-Oriented Design) book.

V

[Phlip]

enki wrote:

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 = getUserNumberFr omUI()
ticket = database.getTic ket(usersNumber )

if ( ticket and
ticket.day == today and
not ticket.isWashed Yet() and
ticket.isCredit Checked() ) then
UIdisplay("PLEA SE ENTER CARWASH")
ticket.isWashed Yet(true)
return true
else
UIdisplay("WRON G 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.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand

[David Harmon]

On 8 Jul 2005 12:45:20 -0700 in comp.lang.c++, "enki"
<en*****@yahoo. com> wrote,

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.

Read the 1972 paper by David Parnas "On the criteria to be used in
decomposing systems into modules".
PDF at http://doi.acm.org/10.1145/361598.361623

Everywhere that Parnas writes "module", you substitute "class".

[Panjandrum]

Victor Bazarov wrote:

enki wrote:

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.

I think you're in a wrong newsgroup. Please try 'comp.object' or a good
OOD (Object-Oriented Design) book.

Maybe it's you who is in the wrong newsgroup. Concepts play an
important role in STL:
http://www.sgi.com/tech/stl/stl_introduction.html

[Shane Mingins]

"Phlip" <ph*******@yaho o.com> wrote in message
news:4b******** ********@newssv r31.news.prodig y.com...

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.

Further analysis ....

Use Case 100: Oh $%&%^&* it scratched the car!!

What should we do?

Carwash SME: Well we'd need to record the car details as part of our
diagnosis of the fault.

May need a new Value Object ..... we could call it Car ... we could call it
Vehicle ... we could call it ObjectInTheCarW ash ... I'd probably start with
Car

:-)

Shane

--
" We should turn our attention back to pleasing our customer. That's what
keeps the paychecks rolling in." -- Ron Jeffries

[Phlip]

Shane Mingins wrote:

Use Case 100: Oh $%&%^&* it scratched the car!!

What should we do?

Carwash SME: Well we'd need to record the car details as part of our
diagnosis of the fault.

May need a new Value Object ..... we could call it Car ... we could call it Vehicle ... we could call it ObjectInTheCarW ash ... I'd probably start with Car

class Scratch {
string make;
string model;
string year;
string vin;
string location;
}

Okay. Now push that into a database and normalize it, and you have a Car
table. Maybe...

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand