From: Ron Jeffries <ronjeffries@...>
Date: 2002-02-26T01:04:08+09:00
Subject: Style Question

So I'm building this set theory library. The "only" object is supposed
to be a Set. Set is really abstract, and there are various concrete
subclasses of Set, such as EnumeratedSet. Users are supposed to be
indifferent to the concrete class, as all the classes are polymorphic
and the selection of which one to use is up to the implementation.

The top level class (now called Set) needs to be abstract. Concrete
subclasses will inherit from it or from other concrete subclasses as may
be appropriate.

So what I've got now is that Sets are created by factory methods such as

  Set.create(anArray)

which returns an EnumeratedSet whose contents are the elements of the
Array, wrapped as they need to be for the set's purposes.

Of course (he said, after finally figuring it out) this means that no
one can do Set.new(anything), because that will implicitly call
initialize and MUST return an instance of Set, which is illegal because
Set is abstract. I guess that's OK with me.

I could build a separate class, SetFactory, and do things over there,
but in Ruby I see no reason to do that. I'm comfortable with a bunch of
factory methods on Set, such as Set.create, except that for those
methods to compile, all the concrete subclasses that Set uses have to be
at least declared before they are used. So the top of the code looks
like this:

class Set
end

class EnumeratedSet < Set
  def initialize (anArray=[])
    @elements = []
    anArray.uniq.each { |atom| insert atom }
  end
end

class Set
  include Enumerable
	
  def initialize (anArray=[])
    raise 'Cannot do Set.new'
  end

  ...
end

and so on. So my question is, is this good style, and if not, what would
be better? Recall that the clients of Set should never need to know
about any of the concrete classes.

Thanks,

Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.