Re: Clean Object Class Design -- Circle/Ellipse

Dmitry Kazakov wrote in message <3b89f4e2.306015_at_news.cis.dfn.de>...
>On Sun, 26 Aug 2001 15:44:58 -0400, "Bob Badour" <bbadour_at_golden.net>
>wrote:
>
>>>I would not force the domain set of a subtype be a subset (in ADT
>>>sense, i.e. via a conversion) of the domain set of the base, because
>>>it excludes generalization. For instance, it would be impossible to
>>>extend an enumeration type and re-use some methods from the base.
>>
>>Assuming polymorphism, a variable declared on the base can have any value
>>declared on the subtype, which makes the subtype a subset regardless.
>
>Why so? Can you elaborate, please?

Simple. If I can assign any subtype value to a variable declared on the supertype, then the subtype's values are a subset of those allowed for variables of the supertype. Likewise, if I can pass any value of the subtype to any operation defined on values of the supertype, then the subtype's values are a subset of those allowed for any operation defined on values of the supertype.

>>>>>All
>>>>>depends on what is "property". Consider a situation when object's size
>>>>>is a property or its memory location is a property and here you are.
>>>>
>>>>Such an object class does not encapsulate its representation, which
should
>>>>be the first clue to a poor design.
>>>
>>>Usually yes, however there are exceptions. Consider an allocator.
>>>Such a program would possibly use the object size, which is then
>>>should be exposed in the interface.
>>
>>The size will depend on the representation and not on the type. Physical
>>independence requires us to keep them separate.
>
>Yes, the size depends on the representation, so what? You know, the
>implementation of practically every method depends on the
>representation.

Again, physical independence may require the DBMS to use multiple implementations of some methods. The allocator will have to allow the DBMS to store multiple different representations of the same type each with possibly a different size -- this means that size itself cannot be a property of the type.

The DBMS internally knows the size of the physical representation it is using without making that a property of the type.

>Applying your argument one may disallow any methods of
>any type.

How so?

>But the things are as simple as that: if the developer
>exposes a method [that returns the object's size, for instance] it is
>no more implementation issue.

You are missing the point that the "size" the developer exposes necessarily represents the size of only one representation regardless of any other representation used, and this does not prevent the DBMS from using other representations without affecting the "size" the developer exposed. Received on Sat Sep 01 2001 - 03:34:59 CEST