In multiple occasions it has been shown that classical pattern works faster and uses less memory compared to anything else out there. It also consumes less resource (memory wise) and it is the most often used pattern currently as well which soft of guarantees that your code will be compatible with other people's code. Recent blog post even compared the exact amounts of memory consumption comparing classical pattern versus Object.create (sorry, could not find relevant link now, but basically the memory overhead was there, but not as big as in other patterns).
However there are proponents of the prototype inheritance pattern in the community as well. On multiple blogs one can see examples of the usage and encouragement to try it out. On also many instances the cited benefits are dubious and refuted by proponents of the classical pattern.
Coming from closure library the classical pattern was the defacto only possible solution for my code up until very recently. However these days I have the chance to once again write code exclusively for modern browsers. I decided to explore what will be possible if I use all the 'wrong' and 'dangerous' patterns to make my code simpler and easier to use.
For the exercise I will have a fictional data server that returns list of records that I want to work with. The very basic use case of just retrieving the data and having it ready for manipulation will be investigated. So, we have a server call that returns an array of objects and basically I want to apply behavior on top of it.
Our server data will look like this:
var serverData = [{
id: 1,
name: 'Peter'
}, {
id: 2,
name: 'Desislava',
lives: 10
}];
There are two classical approached for this (mostly utilized in the 'data' frameworks these days).
1. Wrap the data: basically execute the logic as constructor function and put the data inside of it (for example as this.data = serverData, then operate over the data with access methods (either general: get('name') or named ones (getSomething/setSomething)). By the time the data need to be saved on the server the stored value is used (this.data).
2. Use functional approach: operate on the data via functions defined specifically for the data and pass the data record to every function call. To save the data back on the server pass directly the data as it is.
I was interested in a more 'natural' approach: using the literal objects created by the JSON parsing, slap the behavior on top of it without actually polluting the data and pass the augmented data back to the server directly (i.e. combination of the two approached above).
For this to work we have to be able to:
a) slap the methods on top of a literal object
b) have pure prototype inheritance to tweak the behavior easily
I came up with this:
Object.createPrototype = function(proto, mix) {
function F() {};
F.prototype = proto;
var newProto = new F();
mix.forEach(function(item) {
Object.mixin(newProto, item);
});
return newProto;
};
Object.mixin = function(obj, mix, restrict) {
for (var k in mix) {
if (typeof mix[k] == 'object') continue;
if (restrict && obj[k] != undefined) continue;
if (k == 'applyPrototype') continue;
obj[k] = mix[k]
}
};
Object.prototype.applyPrototype = function(proto) {
if (this.__proto__ != Object.prototype && this.__proto__ != Array.prototype) {
throw new Error('The object is already typed');
}
this.__proto__ = proto;
};
Object.createInstance = function(that, proto, def) {
that.applyPrototype(proto);
if (typeof def == 'object')
Object.mixin(that, def, true);
if (typeof that.initialize == 'function') {
that.initialize();
}
return that;
};
What this allows me to do with the server data is like this:
// define some defaults (if the data on server could have null's)
var defs = {
lives: 10
};
// Define basic behaviour
var Base = {
update: function(data) {
if (this.uid != data.uid) {
return;
} else {
Object.mixin(this, data);
}
},
get uid() {
return this.id;
}
};
//Upgrade the behavior
var Sub = Object.createPrototype(Base, [{
kill: function() {
this.lives--;
}
}]);
// helper function to process an array
function processData(data) {
data.forEach(function(item) {
Object.createInstance(item, Sub, defs);
});
return data;
}
// Upgrade to an array that knows how to handle our data types
var MyArray = Object.createPrototype(Array.prototype, [{
getById: function(id) {
return this.map[id];
},
initialize: function() {
processData(this);
this.map = {};
this.indexMap = {};
this.forEach(function(item, i) {
this.map[item.uid] = item;
this.indexMap[item.uid] = i;
}, this);
},
add: function(item) {
if (typeof item.uid == 'undefined') {
Object.createInstance(item, Sub, defs);
}
Array.prototype.push.call(this, item);
this.map[item.uid] = item;
this.indexMap[item.uid] = this.length - 1;
},
push: function() {
throw new Error('Use the "add" method instead');
},
pop: function() {
throw new Error('Use "remove" instead');
},
update: function(item) {
if (typeof item.uid == 'undefined') {
Object.createInstance(item, Sub, defs);
}
this.map[item.uid].update(item);
},
remove: function(item) {
if (typeof item == 'number') {
this.splice(item, 1);
} else {
if (item.uid == undefined) {
Object.createInstance(item, Sub, defs);
}
this.splice(this.indexMap[item.uid], 1);
}
}
}]);
// Make new type that has next and previous.
var Linked = Object.createPrototype(MyArray, [{
initialize: function() {
MyArray.initialize.call(this);
this.index = 0;
}
}]);
Object.defineProperty(Linked, 'next', {
get: function() {
console.log(this.index)
if (this.length > this.index + 1) {
this.index++;
return this[this.index];
}
else return null;
}
});
Object.defineProperty(Linked, 'previous', {
get: function() {
if (this.index - 1 >= 0) {
this.index--;
return this[this.index];
} else return null;
}
});
// Process the server data to create local data and work with it.
var clientData = Object.createInstance(serverData, Linked);
clientData.getById(1).kill();
clientData.add({
id: 3,
name: 'Denica'
});
clientData.update({
id: 3,
name: 'Ceca'
});
clientData.remove({
id: 3,
name: 'Ceca'
});
var myNextObjetc = clientData.next;
JSON.stringify(clientData); // returns the actual array only without any of our custom props.
// [{"id":1,"name":"Peps","lives":9},{"id":2,"name":"Des","lives":3}]
This is not much improvement over the classical approaches yet, because for example I still cannot update an item in the collection directly with values (i.e. clientData[1] = {id: 2, name: 'Another name'}), which can be achieved if I was simply hiding the array inside a wrapper object. However I believe for the objects inside the list it is a great improvement to be able to just have the behavior stamped on top and yet having natural access to all properties (i.e data.property1.property2. This again is not an ideal situation, because updates are not catch (i.e. bindings will be harder to implement), but this can be resolved by the observer/mutator API proposed.
Again, this is not a real world scenario, just me playing a little bit with literal objects as pure data, but instead is an interesting experiment in the sense that I have always wanted to be able to merge data with logic without too much fuss. What is accomplished in this solution is that we have the data (importantly - ready to be submitted back) and the logic is simply an object we can play with and model, including in run time. All this is possible with other approaches as well, but this is interesting because we do not actually create instances, but instead use the original data instances all the time and simply apply logic on top of it. In conclusion this is like merging the two classical approaches: keep the data instances but have logic bound to it.
DO NOT use this in your code! __proto__ is not standard and getters/setters as well as defineProperty are not widely supported!
CLARIFICATION: I am aware that the same effect could be accomplished with the new Proxy API, so thanks for reminding me, I already know it:)
Няма коментари:
Публикуване на коментар