[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Colin Putney <address@hidden>*Subject*: Re: OO should break when broken(was re: the benefits of immutability)*From*: address@hidden*Date*: Tue, 2 Sep 2003 02:01:57 +0300*Cc*: address@hidden*In-reply-to*: <B29CB210-DCB3-11D7-B3F4-000A27B4C27A@wiresong.ca>*References*: <B29CB210-DCB3-11D7-B3F4-000A27B4C27A@wiresong.ca>*Sender*: address@hidden*User-agent*: Internet Messaging Program (IMP) 3.1

Quoting Colin Putney <cputney@wiresong.ca>: > [...] Subclasses are subtypes, and do have a is-a, a-kind-of > relationship with their parents. The problem is that geometric types are > defined differently than class types. Are they? The set of circles is-a subset of the set of ellipses. Every circle is-an ellipse and every circle is-a-kind-of ellipse. > Shapes are defined in terms of constraints. To create a subtype, you > add constraints. So a quadrilateral is a polygon with four sides, a > rectangle is a quadrilateral with right angles at the vertices, a > square is a rectangle with sides of equal length. Classes types are > defined in terms of state. To create a subclass you add state. (We'll > ignore behaviour for now.) I think that the above reasoning has two major errors. 1. To create a subclass does not require to add state. However, when one adds state in a subclass, one usually constraints the superclass state in respect to the additional state in the subclass. More formally, if the set of valid states of the superclass is V(p) and the set of valid states of the added state in the subclass is V(b\p), then the set of valid states of the subclass is generally a subset of V(p) x V(b\p), where x denotes the cartesian product. More strongly, I would claim that a subclass is only meaningful if the set of valid states is a proper subset of V(p) x V(b\p), because otherwise the added state essentially does not add any semantic information and you could just as well use a simple pair to represent the same information without subclassing. Stated in another way, the essense of a subclass is to constrain the set of states of the superclass. 2. One just can not generally ignore behaviour (= functions and procedures) when dealing with software. Representational (data) hierarchies are useless unless they satisfy useful invariants that can be exploited by behavioral entities (= functions and procedures). > To model a shape with a class you have to include enough state to cover > the range of variation allowed by the constraints. The more specific the > geometric subtype, the more constraints it has, and the less state is > required to model it. So the type hierarchies of shapes and the classes > that model them have an inverse relationship. That's why all circles are > ellipses, but all Ellipses are Circles. So, would you derive a class representing Complex numbers from a class representing Real numbers? Why or why not? Why would or wouldn't you treat the Ellipse-Circle situation in the same way? Regards, Vesa Karvonen

**Follow-Ups**:**Re: OO should break when broken***From:*Colin Putney <cputney@wiresong.ca>

**References**:**Re: OO should break when broken(was re: the benefits of immutability)***From:*Colin Putney <cputney@wiresong.ca>

- Prev by Date:
**Re: OO should break when broken(was re: the benefits of immutability)** - Next by Date:
**Re: OO should break when broken(was re: the benefits of immutability)** - Previous by thread:
**Re: OO should break when broken(was re: the benefits of immutability)** - Next by thread:
**Re: OO should break when broken** - Index(es):