Mywiki2
Subclassing
Subclassing is a principle of creating a specialization(subclass/ derived class) of a base class(superclass/ parent class) by inheriting the methods and instance data from the baseclass.
Why do we Subclass?
1. Code reuse 2. Specialization: A subclass can define new methods it's superclass does not handle. 3. Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation.
Is Subclassing same as Subtyping?
Subtyping
A is said to be a type of B if A's specification is same as B's. Subtypes should satisfy the Liskov Substitution Principle which states,
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2, then S is a subtype of T.
In most programming languages,for example java, ruby, C++, subclassing does not essentially mean subtyping. For a class to be a subtype, the subclass must follow the Liskov Substitution Principle. However it is easy to override a method with a completely new implementation and with stronger constraints. This is not checked by the compiler and we can create subclasses which are not subtypes. This is considered a bad approach, one of the reasons being, an argument to a method may be declared of one class A, but the method may be called with an argument of some subclass B. If we do not know if B is a true subtype of A, then we cannot assume that the behavior guaranteed by A is actually guaranteed by B, and so we cannot reason locally about this method[link mit reference].
Subclass not Subtype
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}
class B {
int y;
int get_y()
{
return y;
}
int sum(B b)
{
if(y > 0)
return x + b.x + y + b.y;
else
return 0;
}
}
Subtype
class A {
int x;
int get_x()
{
return x;
}
int sum(A a) { return x + a.x }
}
class B {
int y;
int get_y()
{
return y;
}
int product(B b)
{
return x * y * b.x * b.y;
}
}
Four perspectives of Inheritance
The four perspectives help in determining when to subclass
Code Reuse
Code reuse is the practice of using the same segment of code in multiple applications.
'Is Code Reuse alone a sufficient reason to use Inheritance?' No It is not.
Consider the following example.
class Automobile_Part
{
String name;
String manufacturer_name;
int part_id;
void setManufacturerName(String mname)
{manufacterer_name=mname;
}
int getPartID()
{return part_id;
}
}
class Medicine extends Automobile_Part
{
String cures_disease;
String getDiseaseName()
{
return cures_disease;
}
}
Here the Medicine class extends the Automobile_Part class in order to reuse the attributes "name" and "manufacturer_name" and "setManufacturerName" method. But it also inherits the "getPartID" method which is not appropriate for the Medicine class.
So Code Reuse is in itself not a sufficient reason for using inheritance.
So if one wants to only achieve code reuse ,they can do so using Composition rather than Inheritance.
'Then what is Inheritance for?'
Inheritance is a mechanism used to facilitate polymorphism and to achieve categorization. By using inheritance one can build a hierarchy of concepts separated in categories at different levels of abstraction. By doing this, you can efficiently use another OOP concept, polymorphism, which allows the same control code to manage all objects in a category even if they are different in their implementation.
Is-A Perspective
Now let us consider both "is-a" relationship and Code reuse perspectives.
'Is the combination of code reuse and the “is-a” relationship among the classes a sufficient reason for using subclassing?'
Consider the following example.
class Bird
{
String name;
String getName()
{
return name;
}
void fly()
{
...
}
void altitude()
{
...
}
}
class Penguin extends Birds
{
void fly()
{
throw new Exception();
}
void altitude()
{
throw new Exception();
}
}
Even though Penguin is a Bird and Penguin class re uses the code in Bird class ,it is not appropriate to use inheritance here because the behavior of the inherited code is being changed.
Consider the case where a user invokes the method "altitude" in the Penguin class .The "altitude" method in Penguin class when invoked instead of displaying the altitude at which the bird flies it throws an exception thereby confusing the user.Code is not considered elegant if the user of that code is surprised or confused by the behavior of that code.
This violates the Principle of Least Astonishment
If a client thinks he has a reference to an object of type A but actually has a reference to an object of subtype B, there should be no surprises when he sends messages to the object.
So according to Principle of Least Astonishment whenever a sub class inherits functionality from the Super class.The subclass is not allowed to change the existing behavior by over ridding the inherited methods.
This also violates the Liskov Substitution Principle because both the "fly" and "altitude" methods of Penguin class doesn't do everything that "fly" and "altitude" methods of its parent class Bird does.
Therefore the combination of code reuse and “is-a” relationship among the classes is not a sufficient reason for using subclassing.
Public Interface Perspective/ Behavioral subtyping
Classes are programmed to interfaces and interfaces might have an overlap in functionality. One interface(subinterface) can extend another(superinterface).
interface B{
void common_method1(B b);
}
interface A extends B,C{
void common_method2(A a);
void common_method3();
}
A a = …;
A a1 = …;
a.common_method1(a1); // Behavioral subtyping – Argument of type B is replaced by its
// subtype A
Interface A includes methods from B and C and transitively above B and C. An interface is considered a type. When A does everything B does and more, A can replace B wherever it is used. This is called behavioral subtyping, and A is a subtype of B. For behavioral subtyping, LSP has to be followed.
Dale Skrien, in his book, suggests the following guideline for subclassing, "If a class B models a role played by class A, especially a temporary role,then B should not be a subclass of A. Instead objects of class B should have references to objects of class A."
An example why inheritance should not be applied when the public interfaces for concerned classes are same but the above guideline does not hold
class Person{
String name;
...
...
}
class Student extends Person{
...
}
class Employee extends Person{
...
}
Here the student and employee classes inherit from Person. "Student" could be an "Employee". Since both student and Employee classes extend Person, they have the data fields of Person duplicated. A reference to a Person object would be a better option than inheritance.
Polymorphism
If all occurences of class A could be substituted by class B then it's good to have class B subclass A to avoid code duplication and by this we follow the LSP principle.
References
http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html
http://en.wikipedia.org/wiki/Code_reuse
http://www.isase.us/wisr3/7.pdf
http://littletutorials.com/2008/06/23/inheritance-not-for-code-reuse/