CSC/ECE 517 Fall 2010/ch2 2c ck

Prototype Based Inheritance

Introduction

Dictionary Definition: An original, full-scale, and usually working model of a new product or new version of an existing product.^[1]
"... the prototype approach in some ways corresponds more closely to the way people seem to acquire knowledge from concrete situations"^[2]
Since the early period of implementation of Object Oriented Design (OOD), there have been two schools of thought concerning the best method of implementing OOD. The class approach, which is the static method of implementation. And the Prototype approach, which is the dynamic method of implementation.

Delegation

The mechanism for implementation of prototyping is called Delegation.^[2]
Delegation is a process whereby an existing object dynamically searches for properties and methods first within itself, then if an match is not found, it delegates that search to its parent object. The parent then repeats the exact same delegation process until a match is found. Once a match is found the result is returned to the requester.

Simple Example
This example demonstrates two objects that I always want aligned on the same y axis, however I want them to be independent on the x axis.

Box remains as is but Point is changed

NOTE: In the above example Box.GetPoint() would also return [10,10]. When GetPoint() searches for X it starts at the original requestors level and uses delegation just like the method search for Box.GetPoint().

While delegation is simple in its design, we will see that it is also elegant. In that it opens the door for several different techniques which allow software developers to morph an existing object, into a much larger and more robust object. While still retaining the original objects simplicity.

Competing Approaches

Class Approach

New objects are made from predefined classes. A class definition must exist to create an instance of a class. When a class is changed, existing objects must be reconstructed and we also need to ensure that nothing else in the application requires the prior classes constructed behavior.

Prototype Approach

New objects are constructed by copying an existing object. After copying we are safe to change the class behavior knowing that we are independent of all other objects. Prototyping is dynamic allowing us to create a real world object as a single instance and then refactor it at run time.

• We can add to it.
  
• We can remove parts from it.
  
• We can break parts out and move to a different location in the same delegation tree. Thereby extending the original behavior to more objects in the same object hierarchy.
  

Contrasting Development Styles

Class Development Style	Prototype Development Style
Must think about objects abstractly and develop a model to simulate behavior	Most people can think clearly about objects that already exist
Many people lack the ability to perform well when working with abstract thoughts	Most people have the ability to perform well when working with real world objects
Good communication is limited to those that can think abstractly	Good communication is open to normal methods of everyday interaction
Real world examples need to be broken down to a model and then reconstructed before they can be worked with	Real world examples can be worked with in real time, there is no need to model behavior

Analysis

Advantages of Prototype

• Reduces development time.
  
• Reduces development costs.
  
• Developers receive quick results and can move on to the next task.
  

Disadvantages of Prototype

• Can lead to insufficient analysis.
  
• The performance may be degraded by prototype overhead.
  
• Can cause systems to be left unfinished and/or implemented before they are ready.
  
• Sometimes leads to incomplete documentation.
  

Prototype Inheritance

As we will see, some dynamic languages use prototyping to support dynamic inheritance and multi-inheritance. This is a level beyond the facilities that extensions provide.

Real World Example

A bank account

Class Approach

Focus of thought is constantly changing:

1. Start with use cases
   
2. Create a class diagram
   
3. Write Code
   
4. Experiment
   
5. Modify class diagram
   
6. Refactor
   
7. Write Code
   
8. Rewrite code that depended on the functionality removed from prior class diagram.
9. Goto step 4
   

Prototype Approach

Lets just build a bank account object and code it right now.

Now I can show it to other people and get their inputs.

I show my account to Mary and she interacts with it.
Mary says that she has several accounts and often transfers money between them.

I add the following to my account object.
  TransferFrom(account, value)
  TransferTo(account, value)

I show the new account object to Bill who is a teller.
Bill replies that he needs to see all of the customers transactions
because sometimes he is asked a question about a particular transaction.
Bill adds that if management approves the dispute, he needs to be able to modify a prior transaction.

I add the following to my account object:
  TransactionHistory [[date location amount],[date location amount],[date location amount]]     
  DisplayTransactionHistory()
  AddTransaction(DateTime, Location, Amount)
  AdjustTransaction(DateTime, Location, NewAmount)

Now that I am tracking transactions, I want deposits, withdrawals and transfers to create transactions.
Therefore, I also add the following: 
  Deposit(value) 
  Withdrawal(value)  
  TransferFrom(account, value)
  TransferTo(account, value)

Now I have an awesome account object, but I only have one.
<pre>
I need a way to copy this object so that I can give accounts to all of my friends.
I then add the following
  Clone()
However, I want Clone() to be available to all existing objects.
Instead of delegating from Clone to TransactionAccount,
I am going to delegate from BankAccount to Clone.

I would also like a ToString() for all objects.
But, I do not need a Clone.ToString().
I am going to delegate from BankAccount to ToString.

References

[1] Yahoo Online Dictionary - Prototype
[2] Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems By: Henry Lieberman
Classifying Prototype-Based Programming Languages
Self - The power of Simplicity By: David Ungar and Randall B - 1986
Prototype and Scriptaculous in Action By: Dave Crane; Bear Bibeault; Tom Locke; Thomas Fuchs ISBN-10: 1-933988-03-7