From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,953e1a6689d791f6
X-Google-Attributes: gidfac41,public
X-Google-Thread: fdb77,953e1a6689d791f6
X-Google-Attributes: gidfdb77,public
X-Google-Thread: 1108a1,6806d4da9f37ac7c,start
X-Google-Attributes: gid1108a1,public
X-Google-Thread: f79bb,953e1a6689d791f6
X-Google-Attributes: gidf79bb,public
X-Google-Thread: 103376,953e1a6689d791f6
X-Google-Attributes: gid103376,public
From: shang@corp.mot.com (David L. Shang)
Subject: Re: Eiffel and Java
Date: 1996/11/12
Message-ID: <1996Nov12.143451.16691@schbbs.mot.com>#1/1
X-Deja-AN: 196093423
sender: news@schbbs.mot.com (SCHBBS News Account)
references: <5694r8$c9c@mulga.cs.mu.OZ.AU>
organization: MOTOROLA 
reply-to: shang@corp.mot.com
newsgroups: 
 comp.lang.eiffel,comp.lang.ada,comp.lang.sather,comp.lang.java.advocacy,comp.object
Date: 1996-11-12T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <5694r8$c9c@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus  
Henderson) writes:
> shang@corp.mot.com (David L. Shang) writes:
> > But separation subtype from subclass is not [good].
> 
> Why not?  Doesn't this also serve to "reduce the dependency
> among software components"?
>
No, the separation subtype from subclass does not help
dependency reduction. Let "A" be a parent class, and "B" be
a subclass but not a subtype. "C" cannot use "B" unless it is
dependent on "B", because depending on "A" does not provide
any polymorphism that can guide the implementation to "B".

However, it helps subclass reuse the code in its parent class
by violating the constraining requirement regulated by its
parent. That is why I say that it is not good.

When a subclass has to violate the regulation, either the subclass
should not be a child, or the parent class provides a wrong
regulation. 
 
> ]In Sather, implementation classes are not always subtype of the
> ]parent class. They merely reuse the code (inherite the implementation)
> ]defined in their parent, but not necessarily be subtype of it.
> ]Without subtyping, the interface provided in the parent cannot
> ]serve as a polymorphic interface for all the implementations.
> 
> Yes, and that's a good thing, isn't it?
> It decouples the interface and the implementation,
> making it easier to use a different implementation.
> 
As I stated above, it does not make it easier to use a different
implementation, rather, it makes it easier to create a
different implementation that is not a subtype, or that
violates the parent's regulation.

> ]In Java, implementation classes are always subtype of the
> ]interface class, but they cannot reuse the code in the interface
> ]class, because there is no implementation in the interface.
> 
> So the code is elsewhere, big deal.  They can still
> reuse it, can't they?
> 
Let's check the client-server architecture.

If Server provides only the interface, then the clients
must provide all the implementation. No reuse.

If Server provides an interface as well as a default implementation
or a set of alternative implementations by a number of subclasses
of the interface, and if the client wants to reuse the implementation
by subclassing, it must inherit the implementation subclass provided
by the sever. If server's implementation changes, the client changes
because it is dependent on the implementation class.

Therefore, the client must reuse the code by aggregation, or by
a "use" relation, not by a "is-a" relation.

Let "A" be the interface, and "B" be the implementation in the
sever. In client, if we want a subclass of "A" to reuse the code
of "B" without dependent on "B", we have to write:

	class C inherit A  // cannot inherit B
	{
		private A imp;
		public void A_method1(...) { imp.A_method1(...); };
		public int A_method2(...) { return imp.A_method2(...); };
		...
		A()
		{
			imp = new B;
		};
	};

It's kind of cumbersome, isn't it? When mutiple inheritance
is invovled, the situition is even more complicated.

Transframe's multiple interface inheritance plus implementation
delegation provides a perfect way for both subtyping and
implementation reuse.

Let A1, A2, A3, ... be the interfaces, and B1, B2, B3 be the
implementations in the sever. In client, if we want a subclass
of  A1, A2, A3, ... to reuse the code of B1, B2, B3 without
dependent on B1, B2, B3, we can simply write:

	class C is A1 by B1, A2 by B2, A3 by B3,...;

For detail, refer to:

	Multiple Inheritance -- A Critical Comparion
	http://www.sigs.com/publications/docs/oc/9611/oc9611.shang.c.html

David Shang