Re: Clean Object Class Design -- Circle/Ellipse

Dmitry A. Kazakov wrote in message <3b913762.1336751_at_news.cis.dfn.de>...
>On Fri, 31 Aug 2001 21:34:59 -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.
>
>It is too limiting.

It is inherent in the idea of subtype and imposes no limit at all. How does it limit anything?

>>>>>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.
>
>So there be no user-written allocators.

The DBA might have considerable control over memory management, but no DBMS should require or allow user-written allocators. No need exists for them.

>>>Applying your argument one may disallow any methods of
>>>any type.
>>
>>How so?
>
>I would argue that DBMS internally knows what is a circle and how to
>deal with it.

No DBMS can internally know all possible types. Someone must describe to the DBMS the types under consideration.

>A good designed language
>should be able to specify in its own terms as many things as possible.

This might be true of application programming languages, but it is certainly not true of data management languages.

If I were interested in discussing application programming, I would point out that such a language requires rare programming skill and discipline. Give a good programmer a powerful language, and the good programmer will make the language do wonders. Give an mediocre programmer a powerful language, and the language will make the programmer do mischief.

>OO languages are going in that direction.

In what direction? Backwards?

>>>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.
>
>It is no matter what DBMS does. The harm is done and any subtype that
>changes the size will violate LSP.

No harm is done. If an object class exposes a property for the "size" of the object represented in XML, it will return the same value even if the DBMS chooses to represent the object some other way. The XML representation and the size of the XML representation will not change.

Since the DBMS does not expose the size of the representation it uses to the object class, the object class cannot violate LSP. At best, the object class must define the meaning of the "size" property using some well-defined abstraction. Received on Sun Sep 02 2001 - 05:29:13 CEST