Mywiki2

From Expertiza_Wiki
Revision as of 00:23, 12 November 2011 by Speri (talk | contribs)
Jump to navigation Jump to search

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.

'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

Public Interface Perspective/ Behavioural 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.

References

http://publib.boulder.ibm.com/infocenter/comphelp/v7v91/index.jsp?topic=%2Fcom.ibm.aix.cbl.doc%2Ftpoot30.htm

http://courses.csail.mit.edu/6.170/old-www/2001-Spring/recitations/recitation4.html