Re: Convenience constructors and non-final setters

On Thu, 5623 Sep 1993 10:26:41 -0500, Lew wrote:
Andreas Leitgeb wrote:
An interesting restriction, whose value I do not *yet* see.
Since the fields are private, any subclass has no choice than use
baseclass's setter for setting them, so whatever validation the
subclass imposes on the attribute, it cannot be weaker than the
baseclass's.

There are scenarios where that isn't true. For example, the derived
class can define its own 'x' and 'y' variables and ignore the parent
class's altogether.

In many cases, if the derived class is going to reinvent much of the
functionality, the base class might be better off as an interface. If part
of the functionality is typically going to be reinvented and part isn't,
consider whether the base class is poorly factored. It may be better off
delegating the reinvented functionality to some inner policy/strategy
object. Alternatively, the base class might neither delegate nor implement
that functionality, leaving it as abstract methods.

But sometimes it does make sense for it to provide a default
implementation of some sort.

I think someone mentioned Point classes and implementations in this
newsgroup recently, and noted that proper encapsulation allowed
reimplementing with polar coordinates.

In this context, someone might be suggesting subclassing the Point to
ignore the parent's xy fields and use its own rd fields in polar
coordinates. In that case, it may be better to make Point and interface
and CartPoint and PolarPoint two separate implementations. In each place
where a Point is required, the best concrete type for the job can be
instantiated.

On the other hand, a ColoredPoint object or some other object with an x
and a y but also other things might be refactored to contain a Point
object (perhaps an interface rather than a concrete type) as above, and
delegate to that or simply expose a getter and possibly a setter for its
Point.

Or it could have abstract methods relating to its position, and
ColoredCartPoint and ColoredPolarPoint concrete subclasses that implement
the position functionality while inheriting the color functionality from
the base class.

However in that case having ColoredPoint implement cartesian coordinates
and ColoredPolarPoint subclass it and replace the position functionality
isn't 100% unreasonable, especially if someone else wrote ColoredPoint,
didn't provide anything else, and you for some reason desire
ColoredPolarPoint. The main downside is that the ColoredPolarPoint object
is a bit bigger than strictly necessary for its job, due to the unused
base class instance fields. If those are two doubles, that's sixteen extra
bytes per object, and it will add up if there are a lot of
ColoredPolarPoints at one time.

For reasons of efficiency and elegance, I'd ordinarily prefer not to have
disused instance state; I consider a desire to override parts of a class
and leave instance state unused to be a smell if I'm in control of the
base class, and typically refactor it to delegate or abstract the
associated functionality, or even make it an interface type.

I believe java.util.random has also been mentioned recently. It is a
classic case where it would have been better to provide an interface, or
perhaps a wholly abstract class with a factory method to supply the
default implementation. The model for the latter pattern would be
Calendar/GregorianCalendar, of course, and for the former List/ArrayList
or similarly. Making Random an interface could have avoided the entire
"constructor calls setSeed" mess, in particular.

--
blue indigo
UA Telecom since 1987
.

Relevant Pages

  • dodefault?
    ... In adding drag and drop functionality I put code into the ... When I run the form and perform my drag and drop it doesn't work because the ... the subclass method and it still doesn't work. ... synchronous so that the base class completes before the subclass code runs. ...
    (microsoft.public.fox.programmer.exchange)
  • Re: MustInherit in Window forms
    ... and it'll be run if the SUBCLASS implementor chooses not to implement ... much depends on whether your base class is usable itself: ... > DisconnectFromAbrServer() method there, and it'll be run if the base class ... > implementor chooses not to implement a custom version of the method. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: using dict for data attributes instead of self
    ... >So why does he wants a dictionary-like base class if he never uses any ... (IMO that __setitem__ subclass override trick is not a good substitute ... BTW, the above was probably written before you could subclass the builtin dict, but now ... A subclass could use lists as additional ways to store info if needed. ...
    (comp.lang.python)
  • Re: Lahman, how ya doing?
    ... >> variety of classes if they were all derived from a single base class ... I regard that as one of C++'s deficiencies because too many ... >people abuse it to navigate from superclass to subclass during routine ... >collaboration because there is only one instance in hand to navigate. ...
    (comp.object)
  • Re: Lahman, how ya doing?
    ... A major reason was the that performance and low-level machine control were primary design objective. ... didn't take me long to realize that a generic pointer can only hold any variety of classes if they were all derived from a single base class, but you can't invoke methods unique to a derived class with a pointer to the base class. ... I regard that as one of C++'s deficiencies because too many people abuse it to navigate from superclass to subclass during routine collaborations. ...
    (comp.object)
Loading