CSC/ECE 517 Summer 2008/wiki1 8 dm
In Lecture 7, we consider prototype-based programming in Ruby. The example that is given is some what artificial. Can you identify real tasks that are easier with prototype-based programming than with class-based programming? Give the code, at least in outline.
Prototype-based Programming
Introduction
As object oriented design becomes more important when designing code, how the objects are designed is becoming a subject increasing scrutiny. There are two major approaches that are commonly implemented. The first is the traditional approach of object-oriented design. Using a starting class that serves as a basis for progressively more complex classes down the line. It could be termed the "Russian Doll" approach. The second approach is prototype-based programming. A prototype class is created with the desired functionality and then simple replicated and extended as needed. It could be termed the "Versioning" approach.
Advantages of Prototype-based Programming vs. Traditional Object-Oriented Programming
Both of these approaches have advantages that play into the nature of design. Traditional programming is a very structured approach which can provide a large scale design with an organized approach. It creates classes that can be reused and it would be structured and extended. If these upper classes need to remain static, this approach will function needed. Any change made to a higher level class will propagate through all class that extend it. However, any time you do not want to modify all instances of the classes you have to create another version of the class. This can create a great deal of complexity but will generally prove more efficient when compiled.
A prototype-based programming creates an object that contains all your initially needed functionality. You create the first object in this manner and can then copy the object if another one is needed. This copy can be extended without creating a new object. This reduces the number of classes that need to be maintained and allows for changes to be made to objects that are not a part of the initial design. You are able to create objects that can store more data if needed.
Prototype-based Example
|class LinkNode
| attr_reader :name, :next, :value
|
| def initialize(name, next,value)
| @name, @next, @value = name, next, value
| end
| by
| def getNext
| next
| end
|end
|
|node1 = LinkNode.new('Dave',nul,nul)
|node2 = LinkNode.new('John,nul,nul)
|
|module StringNode
| def isEmptyString?
| if value == nul
| true
| else
| false
| end
|end
|
|node1.extend(StringNode)
As an example this is relatively primitive but it illustrates the basic concept. A linked list has to act as a container for any number of different manners of objects and these will require nodes customized to those objects. You may not be able to account for those objects in your initial design, so being able to add code afterward without compromising the design. As the example shows, you can simply add a customized module to support any needed functionality.