views:

621

answers:

2

I like Steve Yegge's Prototype Pattern example and decided to whip up a quick proof of concept example.

However, I didn't really think things through. While it is great for dynamically specifying the behaviour of objects and is an easy solution to Steve's opinionated elf example, I'm still trying to work out the best way to handle instance variables.

For instance, let's say I have an AwesomeDragon object. I then want to make an AwesomeDragonImmuneToFire object so I make a new child of the AwesomeDragon (AwesomeDragonImmuneToFire inherits properties from AwesomeDragon) and 'put' "ImmuneToFire" as a property with a value of 'true'. So far so good. Now let's say I want to send my AwesomeDragon object on a tour of nearby peasant villages. This will involve updating the 'position' property of AwesomeDragon. However, the moment I do this AwesomeDragonImmuneToFire will take off as well.

Is the best solution to override instance values upon object creation e.g. immediately 'put' the 'position' value on AwesomeDragonImmuneToFire to the current 'get' value of 'position'?

+8  A: 

Doesn't it depend how you actually implement the inheritance in your system?

For example, in a JavaScript version of what you describe, the prototype for AwesomeDragonImmuneToFire would normally be an instance of an AwesomeDragon, and since you'd always be working with instances, it wouldn't matter what you do to any particular AwesomeDragon:

function Dragon()
{
    this.position = "starting point";
}

function AwesomeDragon()
{
    this.awesome = true;
}
AwesomeDragon.prototype = new Dragon();

function AwesomeDragonImmuneToFire()
{
    this.immuneToFire = true;
}
AwesomeDragonImmuneToFire.prototype = new AwesomeDragon();

>>> var awesome = new AwesomeDragon();
>>> var immune = new AwesomeDragonImmuneToFire();
>>> awesome.position = "flying above village";
>>> immune.position;
"starting point"
>>> immune.awesome
true

In this example, there are no classes and all instances are just instances of Object which happen to know which function was used to construct them. new is just a bit of syntactic sugar and using StudlyCaps for constructor functions is just a convention for functions which are intended to be used with new.

The key thing is that each object has a chain of prototype objects, which is examined if you try to access an attribute which the object itself doesn't hold, as per Yegge's description of what the "Properties Pattern" is.

https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Details_of_the_Object_Model

insin
I thought the idea of the Prototypes was that there were no real classes - only instances of a prototype class. The hybrid principle could work okay I guess but I worry that then you are forced to check object methods and prototype properties.
Graphain
Thanks for the feedback by the way - I like your example and upvoted.
Graphain
There are indeed only instances. However, instance of Awesome used as prototype and instance of Awesome used in worlflow may be different as in example above
Pavel Feldman
+1  A: 

This will involve updating the 'position' property of AwesomeDragon. However, the moment I do this AwesomeDragonImmuneToFire will take off as well.

Maybe I misunderstand but I am not sure why you think the AwesomeDragonImmuneToFire will take off as well. If they are two distinct objects and position is a property of the objects then each instance (dragon) will have their own position. Changing the position of one dragon should not affect the position of the other.

Vincent Ramdhanie
In the prototype pattern properties inherit from the parent object. So until I define a position for AwesomeDragonImmuneToFire it inherits the position of AwesomeDragon.
Graphain