Re: domains aren't subtypes, right?

"Mikito Harakiri" <mikharakiri_at_ywho.com> skrev i en meddelelse news:Ilsza.4$Kj7.85_at_news.oracle.com...
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:DGhza.951082$F1.115813_at_sccrnsc04...
> > So, I sometimes hear this idea that you could create a new type from
> > an existing type. One example I've heard is that you could declare
> > a "city" type (as part of an address) that was in some way derived
> > from the string type.
>
> I would inherit City from Location and define getName method. Err, no, I
> would better derive a City from Village. Now my program is smart, it can
> tell if an address points to a City or Village location! Wait a minute,
can
> I just query population instead?
>
> Seriously, I havent seen more contraversial concept than inheritance. Look
> at those endless LSP debates, for example. I would give you a pass
(couldn't
> resist imitation;-) inheriting City from String if you show me a
> heterogeneous list of String with some Strings being Cities. You also have
> to justify the need to iterate this list and invoke some method for each
> list element. And this method must have different implementation for the
> City and String class.
>

Well, I do understand your humor as there is no mathematically correct way to determine whether one way of inheritance is better then another: as for many other areas in programming (and life!), You need to be pragmatic and define something that looks right - given the constraints of the underlying language.
In this case, however, most object-oriented programmers would agree with me that CITY should neither derive from location or from string. A city has a location (provided a proper definition of this word) and it has a name which could conceivably be represented as a string. This is the traditional "has-a" versus "is-a" issue.

Kind regards
Peter Koch Larsen Received on Fri May 23 2003 - 20:37:57 CEST