Prototype Based Programming Makes A Comeback!

Prototype based (a.k.a. Instance Based) programming is an intriguing alternative to traditional Class based programming. Prototype based programming is usually offered as an alternative to what is arguably the limited modeling capabilities of OO. It usual manifests itself as a programming language (i.e. javascript, Self, NewtonScript). However, recent developments show that its value goes beyond being just a novel object model.

For example, the massively scalable agent platform Cougaar

The first problem that arises in using the Cougaar technology in a large problem domain like logistics is that single inheritance imposes a strict hierarchy on the object classes. This hierarchy imposes unappealing restrictions on the representation of objects and on the re-use of classes.

Another serious problem is that representing all the different types of assets as classes, and all instances of those assets as instances requires far too many classes to be practical. Furthermore, in this approach, the creation of new types of items requires the creation of new classes, and this code must be compiled along with any code that refers to these new types of items.

Using a traditional approach of compiled classes to represent different object types also presents problems in handling time-varying properties of assets, different granularities in descriptions of assets, and different sets of specialized knowledge about assets.

Also take a look at SmartFrog Configuration Description, Deployment and Lifecycle management framework:

SmartFrog does not define types for attributes and components. Rather it defines the notion of a prototype. ... Any attribute whose value is a component description may be, at a later juncture, selected and modified to provide a new component description to be bound to a name. This new attribute may be further modified by subsequent attributes. In this way, it is possible to provide partial definitions, with default values for attributes, to be completed or specialized when used. This provides a simple template mechanism for components.

Consequently, there are no separate spaces of types and instances; every component is logically an instance, but may also be a prototype for another. However, it is clear that in providing descriptions, some components will be defined with the intention that they be used as prototypes for other components, whilst others will be defined without that expectation. Whilst this may appear strange in the first instance, it turns out to be one of the main strengths of the SmartFrog notation.

Finally, outside of implementation and into the world of modeling we find Streamlined Modeling methodology:

It turns out that there are two concepts related to object inheritance that are really useful. First, a child object should be able to act as a partial stand-in for its parent. Second, a child object should be able to answer messages in the same way and with the same values as its parent.

While the second concept seems more obviously useful, the motivation behind making the child object a stand-in for its parent is a little more obscure. The objects that are related through object inheritance represent a single real-world entity. The actor and its roles represent a single person; the specific item and its item description represent a single thing; the composite transaction and its line items represent a single real-world event. When the other objects in the system are working with one of the child objects what they are really doing is working with the combined entity in a particular context. Therefore, the other objects will expect the children to be able to provide many of the same capabilities as their parents.

In addition to useful features there are useful restrictions when applying object inheritance to a business model. Since a child object represents its parent only in a specific context, it does not make sense for the child to be able to change its parent. Any changes made could be invalid in other contexts. Additionally, the parent’s collaborations with other objects should only be visible to its children if they make sense for all of the children of a given type. For example, a line item in a sales transaction would not inherit the relationship between the sale and a subsequent shipment transaction because it is possible that not all line items are included in a given shipment.

As you can see, Prototype based programming has its advantages, unfortunately it continues to be overlooked because of the popularity of Class based programming languages. These examples provide good reason why one shouldn't let that Class based bias restrict one from leveraging a more powerful modeling technique.

In addition, it's interesting to note that Prototype based programming is in fact more loosely coupled. This is due to the fact that the concept of Class and Instance are merged into the same entity. The distinction between both isn't etched in stone, rather it becomes something very fluid. Essentially, the coupling between an entity being a Class or an Instance is hard wired in Class based systems, while in Prototype based systems its dynamic. The eventual result is that pre-mature classification that leads to overly restrictive structures is avoided. Furthermore, classification based on context may also be supported.