[Tutor] Design - getFoo and setFoo methods

alan.gauld@bt.com alan.gauld@bt.com
Sun, 19 May 2002 17:28:38 +0100


> above (I think) an object is there to perform certain actions or 
> behaviors.  This may include the handling/storage of data, but not 
> necessarily.

A object exists to fulfill certain responsibilities(recall 
my earlier post about CRC cards?). The responsibilities will 
either be functionally oriented or data oriented but in 
either case the focus should be on operations not data 
(which should be hidden(aka private).

Jacobsen has the concept of 3 types of objects:
interface - things the user or other systems interact with
controller - things that encapsulate the flow of control 
             of the system
entity - things that hold the state(aka data) of the system

Now this can be abused to create horrid OO systems by turning
functions into controllers and data into entities but provided 
we also apply the Law of deMeter (summarized as "don't talk to 
strangers") we wind up with a nice categorisation of object 
types within an OO system.

> I thought that the idea of object oriented programming was to treat 
> everything as objects, which helps organize your code.  

Correct.

> What you're saying above is that objects don't exist to turn data into 
> objects but rather code constructs into objects.  

Forget data and code they don't exist as separate entities in an 
OO system. All data and code is contained within some object or other.

> to display a Recipient's address.  I would normally do this 
> by creating a method in the Recipient class definition to 
> display an address. 

But read the requirement. You want to display an address so 
the address object should have the display method. Now the 
Recipient may have one too to show all recipuient details 
and in part it will call the address.display()

> .... I would do the same thing but the 
> Recipient's name needs to be a hyperlink that points to a 
> certain page.  

I'm not sure hopw this relates to the address bit?
Do you mean you need to display recipient details where some 
recipients have text names and others URLs? Sounds like a 
job for inheritance/polymorphism and a urlRecipient?
The latters display calls the same address display but 
formats the name as a URL?

Or have I missed the point?

> calling code does the work.  But this seems to be 
> NOT object oriented at all.  

Correct. Refactor the classes to use an Address class 
and subclass recipient to the number of display methods 
you need.

> way around this would be to make a class to display 
> addresses, #

An address class. Its the old noun/verb rule.
nouns = objects, verbs = methods

> a subclass of that which displays addresses with names 
names are separate from addresses. More than one person 
can have the same address!

> What would a Real Programmer do in this situation?

See above, but...
First I'd separate display from the classes.
Get the methods to return a string and let the UI or 
application figure out how to display it to the user.
Thats its responsibility.

HTH,

Alan g.
Author of the 'Learning to Program' web site
http://www.freenetpages.co.uk/hp/alan.gauld