Mywiki2: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
==Subclassing== | |||
Subclassing is a principle of creating a specialization(subclass/ derived class) of a base class(superclass/ parent class) by inheriting the methods and | 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. | ||
instance data from the baseclass. | |||
==Why do we Subclass?== | ==Why do we Subclass?== | ||
Code reuse | 1. Code reuse | ||
Specialization: A subclass can define new methods it's superclass does not handle. | 2. Specialization: A subclass can define new methods it's superclass does not handle. | ||
Method Overriding: An overridding method can either have minor modifications or be completely changed from its parent class' implementation. | 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== | ===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, | 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 | 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. | ||
substituted for o2, then S is a subtype of T. | |||
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]. | 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. 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 | Subclass not Subtype |
Revision as of 00:00, 11 November 2011
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 fewer 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; } }