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

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.