Mywiki2

Subclassing

Subclassing is the concept of creating a specialization(subclass/ derived class) of a base class(superclass/ parent class) by inheriting the methods and instance data from the base class.

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.

/* Include Example here */

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 fewer constraints. This is not checked by the compiler and we can create subclasses which are not subtypes.

Subclassing

Declaring one class to be a subclass of another class there by allowing a

subclass to inherit the functionality from its super class is called

subclassing.

/* we can include here the 4 perspectives of inheritance and then mention

LP principle , principle of least astonishment and some other solid principles of inheritance like the The Open-Closed

Principle and The Single Responsibility Principle.

 */ 

Links for the solid principles... http://www.objectmentor.com/resources/articles/ocp.pdf http://www.objectmentor.com/resources/articles/srp.pdf

Subclassing in Java

Extends Keyword

The extends is a Java keyword, which is used in inheritance process of

Java. It specifies the superclass in a class declaration using extends

keyword.To inherit a class, you simply incorporate the definition of one

class into another by using the extends keyword.

public class A
{ 
   int a;
   char b;
   void method1()
   {
   }
}
class B extends A    //class B inherits the properties of class A
{
   void method2()
   {
   }
}

Abstract classes

Abstract classes in Java are used to declare common characteristics of

subclasses. An abstract class cannot be instantiated i.e an object of an

abstract class cannot be created. It can only be used as a superclass for

other classes that extend the abstract class. Abstract classes are declared

using the abstract keyword. Abstract classes are used to provide a template

or design for concrete subclasses down the inheritance tree.

An abstract class can contain fields that describe the characteristics and

methods that describe the actions that a class can perform. An abstract

class can include methods that contain no implementation. These are called

abstract methods.If a class has any abstract methods, whether declared or

inherited, the entire class must be declared abstract. Abstract methods are

used to provide a template for the classes that inherit the abstract

methods.

Abstract classes cannot be instantiated; they must be subclassed, and

actual implementations must be provided for the abstract methods. Any

implementation specified can, of course, be overridden by additional sub-

classes. An object must have an implementation for all of its methods. You

need to create a subclass that provides an implementation for the abstract

method.

abstract class A
{
  void method1()
  {
    ...
    ...
    ...
  }
  abstract void method2();
}
class B extends A
{
    void method2()
    {
        ...
        ...
    } 
    
}

If the class B does not implement the method "method2" then even class B

has to be declared as an Abstract class.

Rules that should be followed before subclassing

The Liskov Substitution Principle in class typed languages

The Liskov Substitution Principle is a way of ensuring that inheritance is

used correctly.

It states that, in a computer program, if S is a subtype of T, then 

objects of type T may be replaced with objects of type S (i.e., objects of

type S may be substitutes for objects of type T) without altering any of

the desirable properties of that program (correctness, task performed,

etc.).

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 less formal terms, it says that if a client (program) expects objects of

one type to behave in a certain way, then it’s only okay to substitute

objects of another type if the same expectations are satisfied.

Consider the following example which satisfies the Liskov Substitution

Principle

class Bird {

  String name;
  void fly()
  {
     ...
  }
  void altitude()
  {
     ...
  }

}

class Sparrow extends Birds {

}

Example which does not satisfy the Liskov Substitution Principle

class Bird {

  String name;
  void fly()
  {
     ...
  }
  void altitude()
  {
     ...
  }

} class Penguin extends Birds {

  void fly()
  {
     throw new Exception();
  }

  void altitude()
  {
    throw new Exception();
  }  

} If an override method does nothing or just throws an exception, then you’re

probably violating the LSP. Therefore,this does not satisfy the Liskov Substitution Principle though

penguin "is-a" bird.

/* This is a direct lift off so we need to paraphrase it*/

The Liskov Substitution Principle in duck typed languages In programming languages with duck typing (e.g. Ruby, Python, Smalltalk)

classes don’t really define types. There is no type checking when assigning

objects to variables or passing objects as method arguments. There is a

kind of type checking when a method is called. It is checked that the

method exists with a matching number of parameters. Since classes don’t define types, inheritance in duck typed languages has

nothing to do with the subtype relation or the LSP. In a way clients define interfaces in an implicit way. Let’s look at an

example: def my_method1(a) do

   a.m1()
   a.m2()
   my_method2(a)

end

def my_method2(a) do

 a.m3()

end Calling my_method1 with an object a will succeed if the object a provides

the three methods m1, m2 and m3. This is the implicit interface the object

a needs to implement. And with this implicit interface comes the clients

expectation about the behaviour of m1, m2 and m3. That’s just the same as

with the Java interface. If an object b provides m1, m2 and m3 but doesn’t

fit the expected behaviour, the LSP is violated.

The LSP isn’t tied to inheritance or class based typing. It applies to duck

types languages as well as to systems without inheritance. LSP is a concept

that applies to all kinds of polymorphism. Only if you don’t use

polymorphism of all you don’t need to care about the LSP.

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