CSC/ECE 517 Spring 2013/ch1a 1e pi
Inheritance
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both
Means of achieving inheritance
Classical Inheritance Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes. The resulting classes are known as derived classes, subclasses, or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
Prototype Based Inheritance A feature of object-oriented programming in which classes are not present and inheritance is performed via a process of cloning existing objects that serve as prototypes . Delegation is the language feature that supports prototype-based programming.
A simple example of Prototype Based Inheritance could be depicted as
.
(For the sake of an example, do not assume any of the military categories mentioned to be a class. They are all objects. For example we will not create an object for Green Berets. Rather Green Berets is itself an object. This has been done to avoid the use of naming a soldier and then assigning his type to be a private or a green beret or a navy seal, etc) This example shows soldiers belonging to different divisions as different objects. This sort of a relation can be better be represented as a prototype based inheritance than as a class-based one. If the relation used was the classical approach, then a separate class "soldier" would have to be defined as the base class from which the rest of the classes such as delta, green berets and navy seals would have to be defined as children classes. Also these would have been the children classes from which the object itself(probably a real soldier) would have to be instantiated. There is no reason to do so in this case as, each of these, intuitively suit more as an object(real life) than as a passive conceptual class. Besides, the classical approach would bring about a hierarchy among the objects when none exists.
Classical Inheritance v/s Prototype based inheritance
- Object Creation :While in the case of the classical approach, objects need to be instantiated after defining the format of the class, in case of prototype based, a new object can be instantiated by simply creating a copy of/cloning an existing object. As in
Classical inheritance example class Vehicle { //properties }
class Car inherits Land Vehicle { }
class trucks inherits inherits Car { }
class mediumTruck inherits Truck { //properties }
Prototype based inheritance example
class Soldier { //properties }
Private = Soldier.new() GreenBeret.prototype = Private
GreenBeret.weapon=("H&K")
GreenBeret.training=("x months")
- Using Preexisting modules
Prototypes are more concrete than classes because they are examples of objects rather than descriptions of format and initialization. These examples may help users to reuse modules by making them easier to understand. A prototype-based system allows the user to examine a typical representative rather than requiring him to make sense out of its description
- Support for one-of-a-kind objects
Ruby provides a framework that can easily include one-of-a-kind objects with their own behavior. Since each object has named slots, and slots can hold state or behavior, any object can have unique slots or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no linguistic support for an object to possess its own unique behavior, and it is awkward to create a class that is guaranteed to have only one instance. Ruby suffers from neither of these disadvantages. Any object can be customized with its own behavior. A unique object can hold the unique behavior, and a separate "instance" is not needed. In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique behavior. Similarly a private in the army may be trained to handle tanks, (if he were to be in the cavalry division) which makes it unique for the private(army) object. In a class based approach,if private(marine corps) were to be inherited from private(army) and navy seals inherit from private(marine corps) then it would mean that the navy seal would be trained in tanks too, which is not the case here. However in prototype based inheritance training in tanks can remain unique to the marine corps if it is do desired.
References
<references/>
http://en.wikipedia.org/wiki/Prototype-based_programming
http://en.wikipedia.org/wiki/Delegation_(programming)
http://en.wikipedia.org/wiki/Cloning_(programming)