CSC/ECE 517 Spring 2014/ch1a 1a rt: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''Prototype-Based Programming'''
'''Prototype-Based Programming'''


In [http://en.wikipedia.org/wiki/Object-oriented_programming 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. This programming style is also known as instance-base, prototype-oriented, or class-less programming.
In [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], [http://en.wikipedia.org/wiki/Inheritance_(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 [http://en.wikipedia.org/wiki/Cloning_(programming) 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: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]
Previous page on this topic: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Spring_2013/ch1a_1e_pi CSC/ECE 517 Spring 2013/ch1a 1e pi]
Line 10: Line 10:


===Object Creation===
===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
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:
Classical inheritance example:
Line 21: Line 21:
  class medium Truck inherits Truck {}
  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:
Prototype based inheritance example:
Line 30: Line 31:
  Car.prototype = Vehicle.new();
  Car.prototype = Vehicle.new();
  Car.make =("Chevy");
  Car.make =("Chevy");
  Car.Model=("Master Deluxe II");
  Car.model=("Master Deluxe II");


===Delegation===
In class inheritance, methods are either defined in child classes or inherited from their parents. [http://en.wikipedia.org/wiki/Delegation_(programming) 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'''==


===Using Preexisting modules(5)===
===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>


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
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===


===Support for one-of-a-kind objects(5)===
[http://en.wikipedia.org/wiki/Ruby_(programming_language) 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>


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.
===Amending objects===


In the above soldier example, navy seals may be trained in marine combat techniques which makes the navy seal object have its own unique 
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>
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.


==Disadvantages==


===Prototype based inheritance requires dynamic typing===
Because objects are being inherited rather than classes, it is necessary that the language support [http://en.wikipedia.org/wiki/Dynamic_typing#DYNAMIC 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>


===Elimination of meta-regress(4)===
===Refactoring===
In a prototype based system inheritance is built across individual lines of code instead of classes. [http://en.wikipedia.org/wiki/Code_refactoring 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>


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.
===Testing for assurance===
The classical approach offers [http://en.wikipedia.org/wiki/Static_typing#STATIC 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>


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 
===Convention===
properties even though it inherits from the same.
Class base inheritance is more widely used, making programmer unfamiliarity a possible issue. Programmers accustomed to static typing and class inheritance can find prototype-based programming confusing and unpredictable to fix errors.
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.
 
===Transfer of state information on extending the functionality of an object(5)===
 
Using prototype-based programming, we are able to treat any object as a prototype and therefore we can extend the object without having to create a new object. In class-based programming, we are committed to the functionality provided by the object at instantiation. If we later need to extend the functionality of the class-based object, we must instantiate a new class-based object that has the desired functionality and transfer state between the two objects.
 
Consider the transfer of a private from marine corps to green berets. In the prototype-based solution, we simply extend the marine corps
object to have the functionality of a Green Beret. In a class-based solution, we must instantiate a new Green Beret object and transfer state 
from the existing marine corp object to the new Green Beret object.
 
 
===Instances can become templates for other instances in case of Protoype-based Inheritance, not so in class-based(5)===
if you want to [http://en.wikipedia.org/wiki/Cloning_(programming) clone] an object it is easy, just use the existing object as the prototype for the new object. No need to write lots of complex [http://www.go4expert.com/articles/object-cloning-java-t5424  cloning-logic] for different classes.
 
For example, suppose a new program is being introduced to train a junior delta soldier in jungle warfare (say deltaJ), then we simply create a
new deltaJ object by cloning an existing delta soldier(using it as a template) in case of Prototype-based inheritance. However in a class 
based approach, we would have to first create a new subclass deltaJ, instantiate an object of the new class and then write the code to clone 
the existing  delta soldier.
 
 
===Prototype based inheritance is more suited for a [http://en.wikipedia.org/wiki/Functional_programming "functional" style of programming](5)===
In case of prototype-inheritance we write lots of functions that analyse objects and act appropriately, rather than embedded logic in methods attached to specific classes.
Consider the case where a private in the army may be trained with handling an anti-tank weapon or may be trained for handling artillery.
This would be impossible in the class based approach since a private would be a class and only those properties which are generic can be 
embedded in the private's class logic. However in case of the prototype approach, we already know the object so we define the appropriate
function for the object.
 
 
===Prototype based inheritance requires dynamic typing whereas the classical based approach does not(4)===
Since objects are being inherited rather than classes, it is necessary that the language support [http://c2.com/cgi/wiki?DynamicTyping dynamic typing], otherwise there is no way to determine whether the object that is inheriting from another is eligible to possess certain properties.This in turn means increased overhead, as each time an object's functionality is executed, it must be ensured that the object is of a type that has the required functionality.
 
In the above example, a green beret has been cloned from a private(army). However, if at runtime the green beret is cloned from an airman
basic, then all its properties need to reflect those of the new parent. If the language was static then this would simply throw a compiler
error (unless it supported runtime polymorhism).
 
 
===Refactorings don't work the same way(5)===
In a prototype based system we are essentially "building" our inheritance heirarchy with code. IDEs /[http://c2.com/cgi/wiki?WhatIsRefactoring refactoring] tools can't really help us since they can't guess our approach.
 
Consider the vehicle example. Suppose the Car class had a field "type_of_fuel_used". This would not be appropriate as every instance of each 
of its subclass would use a different kind of fuel. Hence it would be better if the field, its setters and getters were moved to the subclass.
This would be a push down refactoring which can be achieved by any IDE. Once the push down has occured any object instantiated from one of the 
3 classes Bus, Truck or SUV would have its own member variable and the corresponding getter and setter.
Now consider the soldier example. Suppose some of the objects - the private, airman, green beret and delta are part of the same division sent 
out on the same mission. Thought the mission is the same, each of them would have a different objective. Thus if objective was a field member
of the private object, it would have to be pushed down to all who have cloned from it. This however the IDE would not be able to do as cloning
occurs at runtime and there is no way to keep track of all the cloned objects to which the member has to be pushed.
 
===Static typing assurances(5)===
The classical approach offers [http://c2.com/cgi/wiki?StaticTyping static typing] wherein the type of an object is determined at compile time. Since all languages that allow prototype based inheritance are dynamically typed, it implies more test cases need to be tested to ensure correct behavior for the latter approach.
 
 
=='''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'''==
<references/>
<references/>
[http://en.wikipedia.org/wiki/Prototype-based_programming  (1)Prototype-based_programming]
[http://en.wikipedia.org/wiki/Delegation_(programming) (2)Delegation_(programming)]
[http://en.wikipedia.org/wiki/Cloning_(programming) (3)Cloning_(programming)]
[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Summer_2008/wiki1_8_smr (4)Work by students from previous semesters]
[http://programmers.stackexchange.com/questions/110936/what-are-the-advantages-of-prototype-based-oop-over-class-based-oop (5)advantages-of-prototype-based-oop-over-class-based-oop]
[http://javascript.crockford.com/prototypal.html (6)Prototype based inheritance in javascript]

Latest revision as of 00:43, 18 April 2014

Prototype-Based Programming

In object-oriented programminginheritance 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>

Convention

Class base inheritance is more widely used, making programmer unfamiliarity a possible issue. Programmers accustomed to static typing and class inheritance can find prototype-based programming confusing and unpredictable to fix errors.

References

<references/>