Categories

Related tags

Scalable JavaScript Application

06 October 2013

Make of JavaScript the language you need

Any diligent developer is constantly working on improving his or her code. There are plenty of books telling how to make your code better. However most of them use the language of class-based OOP. Reader must have enough of experience to reflect those classical design patterns on JavaScript. Thus, many and many developers give up on the language before mastering its true power. That is one of major reasons JavaScript is referred sometimes as The World's Most Misunderstood Programming Language.On the other hand, JavaScript is an incredible impressive language. I wonder if JavaScript was originally designed as a foundation on which you build your own language.

About 2 years ago I had worked out a solution which developed by now into a light-weight library which brings into JavaScript everything I miss in the language as a follower of class-based OOP:

classes containing as members as well as meta-information within their declaration

And as I said that is a light-weight library, about 3K for all those features. Looks promising, isn't it? I hope so, since I'm going to dive into details of how it is implemented and how it feels on a use.

Factory

I'm used to expect from a class an image of what the objects derived from it will look like. I want the class declaration to comprise private and public members and point at its generalization, aggregation and interfaces. Classical prototypal style does not really suit these requirements:

Since we decided that all the objects are being created through the factory, we are really in control of object creation. So we can make the newly created object to inherit from the class specified __extends__ property. The same way we can, for example, aggregate objects enlisted in __mixin__ property. So, we can do many yummy things through the factory and it's unclear which functionally we would like in inject into factory in future. But using hooks it would not be a problem. Thus, we declare a factory hooks collection, accessible for factory plugins. For that we have to change the factory method a bit:

Widgets

JavaScript is often used on DOM-tree, dealing with reusable page representation components (widgets). The most sophisticated pattern I have found so far is YUI Widgets. I especially liked the idea where any object inheriting from WidgetAbstract gets widget behavior such as auto-calling init, renderUi, syncUi, bindUi methods and populating an object with node references based on HTML_PARSER instructions. As you see, that is a part which is easy to implement when having our magic factory. xObject.BaseAbstract constructor assigns a hook which makes object to run init, renderUi, bindUi and syncUi methods right after its creation. xObject.WidgetAbstract constructor adds another hook, preceding the first one. That makes the object to populate node property with node references based on the selectors given in HTML_PARSER (in the context of this.boundingBox).

Interfaces

By interface xObject expects an abstract object that is used to specify an interface (mandatory members and arguments) that classes must implement:

ConcreteInterface = {
methodName : ["string", aClass]
};

Interface plugin assigns a factory hook, which checks if the newly born object meets the requirements of the interfaces enlisted in __implements__ property. It's clear how to check if the object contains members defined by an interface. But how to check member arguments? What I really love in JavaScript, the language allows us to override methods dynamically and that brings an incredible flexibility. We can wrap our members defined by an interface with cross-cutting functionality. In this case it is a check for arguments on the entry point. The plugins expects that interface static object comprises members names where each one points at the array of type hints. Just like in PHP. This way we declare how many and of which types arguments allowed for the members of the object implementing this interface.

DbC

Design by Contract approach provides another and more sophisticated solution of defining requirements for the objects of a type. By a contract we can define not only member the object must have and argument type hints to match on the entry point, but a type hint on exit point and validators for arguments values:

BbC plugin assigns a hook pretty much like Interface plugin does. Unless when wrapping a member it adds a check on exit point too and runs validators over the member arguments. The usage may look like:

Conclusion

xObject is not a panacea of any kind, but it serves me well for years and so it may be useful for you. Besides, you can exploit the idea of a hookable factory to produce your own plugins fitting your peculiar requirements.

Any diligent developer is constantly working on improving his or her code. There are plenty of books telling how to make your code better. However most of them use the language of class-based OOP. Reader must have enough of experience to reflect those classical design patterns on JavaScript. Thus, many and many developers give up on the language before mastering its true power. On the other hand, JavaScript is an incredible impressive language. I wonder if JavaScript was originally designed as a foundation on which you build your own language.

About 2 years ago I had worked out a solution which developed by now into a light-weight library which brings into JavaScript everything I miss in the language as a follower of class-based OOP

Who's the dude?

Dmitry Sheiko is a web-developer living and working in Frankfurt am Main, DE