By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,803 Members | 1,561 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,803 IT Pros & Developers. It's quick & easy.

Classes as concepts.

P: n/a
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.

Jul 23 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
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
Jul 23 '05 #2

P: n/a
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 = 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.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand
Jul 23 '05 #3

P: n/a
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".

Jul 23 '05 #4

P: n/a
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

Jul 23 '05 #5

P: n/a
"Phlip" <ph*******@yahoo.com> wrote in message
news:4b****************@newssvr31.news.prodigy.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 ObjectInTheCarWash ... 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

Jul 23 '05 #6

P: n/a
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 ObjectInTheCarWash ... 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
Jul 23 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.