CSC/ECE 517 Spring 2014/ch1a 1a rt

Prototype-Based Programming

In object-oriented programming, inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both. Class based inheritance required objects to be defined as classes before they are created. In contrast, prototype-based inheritance consists of cloning existing objects which act as prototypes.<ref>http://en.wikipedia.org/wiki/Prototype-based_programming</ref> This programming style is also known as instance-base, prototype-oriented, or class-less programming.

Previous page on this topic: CSC/ECE 517 Spring 2013/ch1a 1e pi

Writeup page.

Classical Inheritance vs. Prototype based inheritance

Object Creation

In classical inheritance, Objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses, or parent classes.

Classical inheritance example:

class Vehicle 
{
//properties
}
class Car inherits Vehicle {}
class trucks inherits inherits Car {}
class medium Truck inherits Truck {}

In prototype based programming, a new object can be instantiated by simply creating a copy of/cloning an existing object.<ref>http://en.wikipedia.org/wiki/Cloning_(programming)</ref>

Prototype based inheritance example:

class Vehicle
{
//properties
}
Car.prototype = Vehicle.new();
Car.make =("Chevy");
Car.model=("Master Deluxe II");

Delegation

In class inheritance, methods are either defined in child classes or inherited from their parents. Delegation is a feature of prototype-based languages that use pointers to find the correct method or data during runtime. The delegation pointer establishes the link between parent and child methods. This allows child objects to be different in structure from their parents and be modified without affecting the parent.<ref>http://en.wikipedia.org/wiki/Delegation_(programming)</ref>

Advantages

Ease of creating object variety

In prototype-based programming, new objects can be quickly cloned and defined in individual lines of code. As well, multiple inheritance is made simple with prototypes compared to class inheritance. Individual data or methods in two unrelated objects can be associated to a child without requiring complete inheritance. This allows for a high density of different prototypes that can be easily maintained. <ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

class Bicycle{}
class ElectricCar{}
Scooter.prototype = Bicycle.new();
Scooter.power_source = ElectricCar.power_source;
//An electric scooter is made from inheriting 
//data from two unrelated classes.

One-of-a-kind object support

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 state or behavior. Class-based systems are designed for situations where there are many objects with the same behavior. There is no 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. A unique object can be customized with its own behavior, and a separate "instance" is not needed.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

Amending objects

Using prototype-based programming, any object can be treated as a prototype, therefore the object can be extended without having to create a new object. In class-based programming, objects are committed to the functionality provided at instantiation. If the functionality of the class-based object later needs to be extended, a new object that has the desired functionality must instantiated and transfer the state between the two objects.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

Disadvantages

Prototype based inheritance requires dynamic typing

Because objects are being inherited rather than classes, it is necessary that the language support dynamic typing. Otherwise there is no way to determine the object's inherited properties. This increases performance overhead, as each time an object's function is executed, it must be ensured that the object is of the correct type for that function.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

Refactoring

In a prototype based system inheritance is built across individual lines of code instead of classes. Refactoring tools and IDEs cannot statically analyze code in a dynamic type system to refactor code.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

Testing for assurance

The classical approach offers static typing where the type of an object is determined at compilation. Since all languages that allow prototype based inheritance are dynamically typed, typically more testing is required to ensure correct behavior and that objects are of the correct type for methods they are called on.<ref>http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop</ref>

Which is the better approach(5)

The classical based method is more traditional and purist compared to the prototype based approach. People used to a conventional OOP style may easily get confused. "What do you mean there's only one class called "Thing"?!?" - "How do I extend this final Thing class!?!" - "You are violating OOP principles!!!" - "It's wrong to have all these static functions that act on any kind of object!?!?" It is really the type of software, objects that are interacting with each other and functionality that determine which approach needs to be used.

For instance, if the above soldier example were about an army rather than individual or special divisions in the army then the classical   
approach would have been more appropriate, as there is already a natural existing hierarchy within the army that can be exploited. It would 
seem vague if different ranks such as lieutenant, corporal, major, general, etc were to be created as objects rather than classes. Also since  
each of these ranks can have multiple instances of real world objects associated with them, performing almost exactly the same functions, it 
would be better to create the ranks as classes and then instantiate each soldier as an object of the respective class.

References

<references/>

(4)Work by students from previous semesters
(6)Prototype based inheritance in javascript