[E-Lang] Re: inheritance, delegation, mental models forbegin ners (was: down with `define' (was: newbie syntax: picayunepoints from a prejudiced programmer))

[Ben Laurie]

"Mark S. Miller" wrote:
> 
> At 05:20 PM Friday 3/2/01, Karp, Alan wrote:
> >MarkM wrote:
> >>
> >> Btw, many of us, when doing class-based programming with inheritance,
> >mostly
> >> stopped using concrete non-final classes since the Udanax Gold days.  When
> >> we found we wanted to subclass a concrete class, we refactored so that we
> >> were subclassing from an abstract class.  [...]
> >
> >I must have been doing something wrong, because I tried to do this (at least
> >I think I did), and I didn't like the result.  Say I have a class C with 2
> >methods, M1 and M2.  One subclass C1 overrides M1, another C2 overrides M2.
> >If C is a concrete class, then C1 gets C's M2, and C2 gets C's M1.  If C is
> >abstract in that it has no implementation for M1 and M2, where do these
> >implementations go?  I ended up with an extra abstract class between C and
> >each of C1 and C2.  Of course, it's not terrible with only 2 methods; my
> >case had 5.
> 
> We're having a terminology problem.  By "abstract class" I mean what Java
> means: A class that cannot be directly instantiated.  Only subclasses of it
> can be instantiated.  You seem to mean a class that has only abstract
> methods, or approximately what Java calls an interface.  Note that a Java
> abstract class need not have any abstract methods.  Merely by declaring the
> class abstract, you prevent it from being directly instantiated.
> 
> So regarding your example in Java, we refactor by leaving C alone but for
> declaring it abstract.  We might then supply yet another concrete final
> subclass C0 that only has a constructor and inherits all its instance
> behavior from C.  Why? So far we've only added noise and no signal.  Because
> we found the resulting code structure was more evolvable.  C is for
> subclassing.  Period.  C0, C1, and C2 are for instantiating.  Period.  No one
> class is maintained under the requirement to do both jobs.

Hmm. You can't do that in C++ - a class is only abstract if it has an
abstract member function. I suppose you could fudge it like this:

class C
	{
	virtual void concrete()=0;
	virtual void doSomething();
	void doOtherThing();
	};

class C0 : public C
	{
	void concrete() {}
	};

class C1 : public C
	{
	void concrete() {}
	void doSomething();
	};

And so forth.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

ApacheCon 2001! http://ApacheCon.com/