Thursday, September 26, 2013

Compose, don't inherit (not a lot anyway).

Lately I've seen a lot about JavaScript Inheritance and in particular different github projects that allow you to do inheritance in a certain way. Most of these solutions are about trying to use some form of classical inheritance and with good reason. If you're used to any other language then that is probably what you learned and so it makes sense. Also there can be performance gains as using a "class" means you won't be mutating an object's signature and as such a JavaScript runtime can make optimizations for that "type".

There are also some good articles about what JavaScript inheritance is really about and if you only read one, make sure to read Kyle Simpsons: JS Objects.

But do we really need long inheritance chains where we link up lots of objects and have lookups going up a chain? As JavaScript is so flexible can we learn things from Functional and Aspect Oriented styles of programming? I think we can.

At Dataminr we've begun the journey of rewiring (it's like rewriting from scratch but using most of the old code, putting it in different places and changing how it's all passed through) our code. It turns out that combining some ideas gives us an easy way to keep a flat inheritance structure where we can compose together objects that we need. To do this though we have to take functionality away from the objects and put them in services that we can pass our objects in to, split some objects apart and with the rest cut them in to little packets of functionality that can be added when necessary. This leaves us with simple objects and a toolbelt of features we can add on as needed in the main file - we get closer to configuring a product rather than actually coding it.

We're currently using Backbone.Advice which I introduced in this blog post. Since starting with that we've learnt a lot about how to structure the application using the AOP approach. Instead of having the inheritance through the constuctors we moved most inheritance over in to the mixins. From the original blog post I mention that you can build ever more complex mixins by adding in other mixins. Doing this we can do things like make a clickToSelect mixin that will call upon the clickable and selectable mixins.

But won't all these mixins get in each other's way and run when they're not supposed to? Perhaps the most important thing when using these mixins is a naming convention. Inside the Backbone.Advice repository there is a mixins.js file that gives some examples in to using mixins. I wouldn't go ahead and use these in production as they're a bit stale from the version we use in production, but looking in to them you can see there is a very deliberate naming convention. We use very simple, very clear names that describe the current action precisely. We do something similar with the options that are passed in to the mixin (as all mixins will share a common options object). For instance we decided there would only be one scrollable element per view so whenever a mixin needs a handle to the element it exists as options.scrollEl - no matter which mixin needs it.

The one thing that we kept coming up against though (as we still have legacy code being used) is that older classes that extend from these base classes were overwriting functions. Sometimes we wanted to overwrite the base function but we always wanted to keep the mixins applied. To fix this we had to come up with a new way of defining the inheritance. So after all this I get to introduce Backbone.AdviceFactory.

Now all we do is register how something is built by defining it's base (if it's been registered before you just call it's string name) and we can go ahead and add in all the functionality through extends or mixins (though it will automatically put functions as "after", extend existing objects and clobber everything else) and the factory will go back through all the bases, work out the extends and then put the mixins on last. This means all the mixins are kept. We can then Instantiate the object through the factory.

It might be better to see an example - I've commented the code so you can see how it works:

define(['Backbone.AdviceFactory'], function(Factory) {

    // register a base:
    Factory.register('view', {
        base: Backbone.View
    });

    // you can extend and mixin
    // it will pass back the new constructor
    var myView = Factory.register('myView', {
        base: 'view',

        // non reserved keywords are mixed in as after if functions
        // or clobber if not
        defaultSize: 10,
        onSelect: function() {console.log('selected')},

        // or you can pass in the extends
        // such as constructors (as they're functions you don't want mixed in)
        extend: {
            // actually itemView is already a special keyword that will extend
            // but it's here for demonstration purposes
            itemView: itemView
        },

        // functional mixins go here
        mixins: [
            myMixin1,
            myMixin2
        ],

        // options for mixins
        options: {
            scrollEl: '.scroll'
        }

        // also any other advice keywords such as after, before & clobber
        addToObj: {
            events: {
                'click': 'onClick'
            }
        }
    });

    var MyView2 = Factory.register('myView2', {
        base: 'myView',

        // this will mixin as "after" automatically
        initialize: function() {}
    });

    // register returns the constructor
    var myView2inst = new MyView2(arg1);

    // to get the finished product:
    var myView2inst2 = new Factory.get('myView2')(arg1);

    // or better yet
    var myView2inst3 = Factory.inst('myView2', arg1);

});

It's an incredibly powerful way of defining objects. As we write more we tend to find that more functionality can go in to mixins and these structures get a lot flatter, and with a lot less functions given to the factory. The functions mostly come from the mixins and only configuration goes in to the objects (though most of that is passed through at instantiation).

The last piece of advice (no pun intended) we could give is that you will come up against recurring structures in your code. Perhaps you have a widget that will always have a list that will always have a header. To deal with these we create factories that will do all the instantiation for you and wire up everything that needs to talk to each other, just pass in the data and any constructors that are different to the default. This leaves us with simple units we can call upon and just pass in the data. We do all this in the main file so all the data is available to use meaning we can setup complex relationships without having to jump through hoops.

I hope this helps some people out there - we've been using this approach and it works extremely well. It has allowed us to cut down on our development time and spend more time at the pub - which really is what development is all about.

5 comments:

  1. There are lots of great reasons to use composition instead of classical inheritance. For more details, check out my talk, "Classical Inheritance is Obsolete: How to Think in Prototypal OO"

    http://ericleads.com/2013/02/fluent-javascript-three-different-kinds-of-prototypal-oo/

    ReplyDelete
  2. With composition you don't keep a single source, you create duplicates as you need. Is this raising any concerns: each duplicate runs its show, and how do you go back the composition chain, if needed?

    ReplyDelete
    Replies
    1. If you find yourself wanting to go back to remove items from the chain then you're probably applying things too early in the chain. Keeping the chain as shallow as possible will help and only applying things when you need them.

      As for duplication of functions, you could declare a function outside your mixin and use a reference so it points to a single function, but in the complex applications I have used this with I haven't seen any performance issues (I have had some objects with over 20 mixins on and that would have a function decorated with more than 6 levels or arounds that would be used over 100 times on the page with other things - approx. numbers off the top of my head).

      Delete
  3. INTERNATIONAL CONCEPT OF WORK FROM HOME
    Work from home theory is fast gaining popularity because of the freedom and flexibility that comes with it. Since one is not bound by fixed working hours, they can schedule their work at the time when they feel most productive and convenient to them. Women & Men benefit a lot from this concept of work since they can balance their home and work perfectly. People mostly find that in this situation, their productivity is higher and stress levels lower. Those who like isolation and a tranquil work environment also tend to prefer this way of working. Today, with the kind of communication networks available, millions of people worldwide are considering this option.

    Women & Men who want to be independent but cannot afford to leave their responsibilities at home aside will benefit a lot from this concept of work. It makes it easier to maintain a healthy balance between home and work. The family doesn't get neglected and you can get your work done too. You can thus effectively juggle home responsibilities with your career. Working from home is definitely a viable option but it also needs a lot of hard work and discipline. You have to make a time schedule for yourself and stick to it. There will be a time frame of course for any job you take up and you have to fulfill that project within that time frame.

    There are many things that can be done working from home. A few of them is listed below that will give you a general idea about the benefits of this concept.

    Baby-sitting
    This is the most common and highly preferred job that Women & Men like doing. Since in today's competitive world both the parents have to work they need a secure place to leave behind their children who will take care of them and parents can also relax without being worried all the time. In this job you don't require any degree or qualifications. You only have to know how to take care of children. Parents are happy to pay handsome salary and you can also earn a lot without putting too much of an effort.

    Nursery
    For those who have a garden or an open space at your disposal and are also interested in gardening can go for this method of earning money. If given proper time and efforts nursery business can flourish very well and you will earn handsomely. But just as all jobs establishing it will be a bit difficult but the end results are outstanding.

    Freelance
    Freelance can be in different wings. Either you can be a freelance reporter or a freelance photographer. You can also do designing or be in the advertising field doing project on your own. Being independent and working independently will depend on your field of work and the availability of its worth in the market. If you like doing jewellery designing you can do that at home totally independently. You can also work on freelancing as a marketing executive working from home. Wanna know more, email us on workfromhome.otr214423@gmail.com and we will send you information on how you can actually work as a marketing freelancer.


    Internet related work
    This is a very vast field and here sky is the limit. All you need is a computer and Internet facility. Whatever field you are into work at home is perfect match in the software field. You can match your time according to your convenience and complete whatever projects you get. To learn more about how to work from home, contact us today on workfromhome.otr214423@gmail.comand our team will get you started on some excellent work from home projects.


    Diet food
    Since now a days Women & Men are more conscious of the food that they eat hence they prefer to have homemade low cal food and if you can start supplying low cal food to various offices then it will be a very good source of income and not too much of efforts. You can hire a few ladies who will help you out and this can be a good business.

    Thus think over this concept and go ahead.

    ReplyDelete