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.

• Elimination of meta-regress

No object in a class-based system can be self-sufficient; another object (its class) is needed to express its structure and behavior. On the other hand, in prototype-based systems an object can include its own behavior; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.

For example in case of the soldier, a Delta force unit is its own object. It does not require a an airman basic object to define any of its properties even though it inherits from the same. However in case of the vehicle example, a medium truck cannot be an object of its own completely. It would need some of its properties to be defined by its superclass 'vehicle'. Consider the move(direction, speed) function defined for the Vehicle class. In most of the cases the medium truck would inherit this functionality completely. It is not likely to have its own move() function.

<references/>

http://en.wikipedia.org/wiki/Prototype-based_programming

http://en.wikipedia.org/wiki/Delegation_(programming)

http://en.wikipedia.org/wiki/Cloning_(programming)