Generalization - implementation for subtyping?

Hi,

Excerpt from Martin Fowler, UML Distilled, Chapter 4, Generalization, Page 61
The key point here is the difference between generalization at the specification prespective (subtyping, or interface-inheritance) and at the implementation prespective(subclassing or implementation-inheritance).Subclassing is one way to implement subtyping.You can also implement subtyping through delegation - indeed, many of the patterns described in Gamma,Helm,Johnson, and Vlissides (1995) are about ways of having two classes with similar interfaces without using subclassing.You might also look at Fowler (1997) for other ideas on implementation for subtyping

Well, there are lots of questions in my mind.Look at my next post
Thanks in advance,
Sandeep

Here is what I got from the paragraph quoted above :
I am taking the same example which Martin uses in this sub-section - Customer class (as super-type) with Personal Customer and Corporate Customer as sub-types.

Originally posted by Desai Sandeep:
Subclassing is one way to implement subtyping.

From the above quote, I believe, Martin might be hinting to consider Personal Computer and Corporate Customer as subclasses of Customer class.I hope, this is what he means by "implement".Hope, he did not mean, to create concrete subclasses of Personal Customer and Corporate Customer sub-types!!!

Originally posted by Desai Sandeep:
You can also implement subtyping through delegation- indeed, many of the patterns described in Gamma,Helm,Johnson, and Vlissides (1995) are about ways of having two classes with similar interfaces without using subclassing.

I am not sure why I would do this.The only reason that I can think of, is to make my code look cleaner.In the above example, if the sub-types (would be comfortable to call it as subclasses,though

), are doing some I-O operations, then I would have a class at a same level with a static method which does the "dirty work" of writing to the file/or updating the DB.This static method would be called by the subclasses - Personal Customer and Corporate Customer.
But we have already subclassed the Customer - so how is delegation preventing subclassing?

Originally posted by Desai Sandeep:
You might also look at Fowler (1997) for other ideas on implementation for subtyping

Sorry, my brain cells have given up at this point.I can not think of any other way to implement the subtype.If any one of you have read "Analysis Patterns" (I think Martin is referring to this book of his!), could you please share this piece of info with me?
Thanks in advance,
Sandeep
[This message has been edited by Desai Sandeep (edited May 26, 2001).]

Refresh please.
Thanks,
Sandeep

Sandeep,
Refer to the "Perspectives" subsection (p.51). Fowler explains the different perspectives and touches on the difference between "type" and "class": "...a type can have many classes that implement it, and a class can implement many types."
The point I think Fowler is trying to make is that when you are looking at a specification level diagram, you should remember that generalization applies to types while in an implementation level diagram, generalization applies to actual classes.
Take for example the different Listener interfaces in AWT. Classes that implement the same listener interface would be of the same type but not necessarily in the same class hierarchy.
Also, in using delegation to implement subtyping, a class may support an interface A (its type is A) but simply passes invocations of methods of the interface (delegates) to a helper object.
HTH,
Junilu

Junilu,
From what you said, I understand that the types in the specification phase may or may not become classes in the implementation phase.There may be a need to subclass a subtype in the implementation phase.
Hence in the Fowler example, Customer (super-type) with Personal Customer and Corporate Customer as sub-types; the sub-types could be considered as actual classes in the implementation phase.
Fowler emphasizes the need to draw the Class Diagram from the specification prespective.However, the thing that puzzles me most is that when we actually start to code, does he mean that we consider all the types as interfaces?
Alternatively, should we have an approach to decide this sub-type infact should remain as a sub-type or this sub-type is more appropriately a sub-class?Also, if this is an approach, how do we draw a line between sub-types and sub-classes?
Hope this makes some sense

,
Thanks in advance,
Sandeep
[This message has been edited by Desai Sandeep (edited May 29, 2001).]

Just think of "type" as the "interface", not in the Java sense but in the sense of making a "promise" to fulfill certain responsibilities.
In the specification-level diagram, all subtypes make the same "promise" that the supertype does (what Fowler calls conforming to the supertype's interface).
That leaves you to implement it in a least two different ways: through interfaces or class inheritance.
In the case of Customer, PersonalCustomer, and CorporateCustomer, if you implement through interfaces, then
you might have a Customer interface, PersonalCustomer class that implements Customer, and CorporateCustomer class that implements Customer. Alternatively, you could have Customer as an abstract class and PersonalCustomer and CorporateCustomer as concrete subclasses. There could be other variations. The point is, regardless of the actual implementation, they still stay true to the specification-level generalization.
Junilu

[This message has been edited by JUNILU LACAR (edited May 29, 2001).]

Junilu,
Thanks, that helps.
This means irrespective of the kind of implementation, we need to see that the responsibilities(types or promises) defined at the specification level is not broken!
- Sandeep
[This message has been edited by Desai Sandeep (edited May 30, 2001).]