Newsgroups: comp.lang.c++,comp.lang.smalltalk,com.lang.eiffel
Path: cantaloupe.srv.cs.cmu.edu!rochester!cornellcs!newsstand.cit.cornell.edu!news.kei.com!nntp.coast.net!torn!nott!cunews!dbuck
From: dbuck@superior.carleton.ca (Dave Buck)
Subject: Re: heterogeneous collections
X-Nntp-Posting-Host: superior.carleton.ca
Message-ID: <DJAv52.1Mo@cunews.carleton.ca>
Sender: news@cunews.carleton.ca (News Administrator)
Organization: Carleton University, Ottawa, Canada
References: <30C6CB85.7B3D@jpmorgan.com> <4a84qd$9ko@newsbf02.news.aol.com> <4aagbe$329@gaia.ns.utk.edu>
Date: Sat, 9 Dec 1995 03:31:50 GMT
Lines: 72
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:164131 comp.lang.smalltalk:31826

In article <4aagbe$329@gaia.ns.utk.edu>,
Matthew B. Kennel <kennel@msr.epm.ornl.gov> wrote:
>Bytesmiths (bytesmiths@aol.com) wrote:
>: We take such programmers out back and shoot them! :-) Better is to
>: determine what it is about a Bond that makes it a bond, and then implement
>: a common message like

We're agreed on the shooting part :-)

>
>:     isBondLike
>:         "Do I have the unique characteristics of a bond?"
>
>If you end up with a question whose answer, for all practical purpose, is
>"am I a Bond" then I think it's better to admit to that instead of pretending
>to not depend on that fact. 
>

I like to use the following approach:

If you want to have a collection of FinancialObject type objects but
there's some behavior you need to run that's specific to Bonds,
consider first:

   - Is this behavior REALLY specific to Bonds or can it be applied to
     all FinancialObjects but in most cases it does nothing or returns
     a trivial result?

If the behavior makes sense for all FinancialObjects even though only
Bonds have interesting behavior for it, you can create a method in the
superclass and then use the same protocol on all objects in the
collection.  For example, "calculateInterest" might be something that
all FinancialObjects may be told to do but only Bonds really use to do
something useful.  This only works well if the operation makes sense
for all FinancialObjects.

If this isn't right for your domain, you can ask:
   - Is there some generalization of this operation which applies to
     all FinancialObjects.  For example, maybe "calculateEndOfTermAdjustments"
     could apply to all FinancialObjects even though
    "calculateInterest" which is called at the end of term is specific
    Bonds.

If this is the case, then you can use the general method in the loop,
and implement the general method for Bonds to simply call the specific
method.  Again, the same protocol is used for all objects in the
collection.

The next most desireable option is to implement an isBondLike method
which applies to all FinancialObjects but only returns true for those
that actually behave like bonds.  The disadvantage of this approach is
that the caller has to have special cases which makes it harder to
manage in the long term, but it's still a far sight better than
isKindOf:.  If this ability isn't needed often and you don't need many
methods of this type, it can be a good solution.

If you find that you have lots of exceptions and special cases for
certain objects in the collection, the best solution might be to use
a different collection stored in a different instance variable.

David Buck
dbuck@ccs.carleton.ca

_________________________________
| David K. Buck                 |
| dbuck@ccs.carleton.ca         |
| The Object People             |
|_______________________________|




