Re: Clean Object Class Design -- Circle/Ellipse

From: Bob Badour <bbadour_at_golden.net>
Date: 10 Oct 2001 19:13:09 -0700
Message-ID: <cd3b3cf.0110101813.479753de_at_posting.google.com>


brangdon_at_cix.co.uk (Dave Harris) wrote in message news:<memo.20011008212857.61375A_at_brangdon.madasafish.com>...
> bbadour_at_golden.net (Bob Badour) wrote (abridged):
> > How does Smalltalk:
> > * allow me to declare circle as a subtype of ellipse?
> > * allow me to send the setFoci message to ellipse variables (that
> > incidentally contain circle values) with two different focal points?
> > * prevent me from sending the setFoci message to circle variables?
>
> If we need Circle to be a subclass of Ellipse, we probably need to make
> them immutable.

All values are immutable, and all variables are mutable. Why shouldn't the language recognize that fact directly?

> So instead of setFoci we would have withFoci. Like:
[snip]
> This returns a new object of the appropriate class, fully initialised.
> Once created, there is no public protocol to change its focii so a circle
> stays a circle.

In other words, one can overcome Smalltalk's deficiency by studiously avoiding the definition of any update operations (except assignment) on variables of the types in question. To change the state of an ellipse variable, replace the entire value of the variable en masse.

This might work for a small and simple class such as Ellipse. What happens when the class has many more attributes and much more complex state? Would the idiom scale?

> Instances of Circle are what you call variables, although that often
> doesn't matter. One potential issue is that, by default, circles can have
> the same centre and radius but different identities. In practice, identity
> is less important for objects which cannot be changed. If it matters, we
> can fix it by using a variant of the Singleton Pattern.

In other words, one can overcome the deficiencies of the language through careful application of ad hoc idioms and patterns. Are there no advantages to requiring additional expertise and skill from the language designer and to requiring less expertise and skill from the language user?

(I must say: It's refreshing that a sensible Smalltalk programmer has finally joined the discussion.) Received on Thu Oct 11 2001 - 04:13:09 CEST

Original text of this message