0
\$\begingroup\$

Ever since reading Crockford's "Good Parts" and Johansen's TDD book, I have wanted to use more of the differential inheritance pattern in my coding at work (as in avoiding new by using Object.create()), but I find that I am having a hard time argumenting for the clearness of the code when trying to make "types" that can be used for object creation. Most of my co-workers are "classically" inclined.

I guess this question somehow boils down to these points

  • downcasing/UpperCasing (i.e. "car" vs "Car")
  • prefixing the base instances (i.e "prototypeCar"). This practice is for instance seen in the code of the author of Fluent Javascript
  • init() methods VS factory methods.

    // init style
    car.init = function(brand) {
        this.brand = brand; 
    }
    myCar = Object.create(car).init("Nissan");
    
    // versus
    
    // factory method
    function createCar(brand) { 
        var o = Object.create(car);
        o.brand = brand;
        return o;
    }
    
    // alternative factory method
    function createCar(brand) { 
        var o = Object.create(car, { brand : brand } )
        return o;
    }
    
    myCar = createCar("nissan")
    

My problem with having lower cased car types is that for someone glancing over parts of the code, they might think that car is an instance of some kind of 'class' Car, and get confused when I suddenly start creating new instances from it. In my opinion, the notion of using a prefix, such as "prototype", seems to more clearly state my intentions with the instance. So do saying Car, but that implies that it should be used together with new, so one should perhaps refrain from that ... (?)

\$\endgroup\$
1
\$\begingroup\$

I see a conceptual issue with this approach: it is nice to inherit from objects, but these entities are not the "real" object. In other words, there is no much sense in using them outside of initialization code. If you need new [Cc]ar then it will not be wise to take any car that is nearby and just modify it and enjoy numerous side effects - you probably need some "etalon" of cars. The Car.

To be honest, I frequently have an intention to use only factory methods in JavaScript and not use the operator new at all. But then I look on how many should I rewrite for that and give up because I do not see the real benefits from this approach - it is not a big task to rename the constructor Something to factory method createSomething and replace it within the code, but what is next?

\$\endgroup\$
  • \$\begingroup\$ Thanks for the reply. I see the point with regards to rewriting, but do you still follow through with it in new (pun intended) code? And which of the patterns do you end up using? \$\endgroup\$ – oligofren Nov 1 '13 at 23:25
  • \$\begingroup\$ In general I have yet to see much use of this way of structuring code for reuse. Usual mixins seem to be more prevalent as an alternative to the "class" style. \$\endgroup\$ – oligofren Nov 1 '13 at 23:29
  • \$\begingroup\$ Currently I'm trying to use the best tool for the task. I rely on the frameworks and common practices in the technology I use. For example, I like Angular directives and node.js modules. For internal logic I prefer functional style (I like pure functions very much in this area), for libraries I design OOP interfaces (I like DOM). Here is one of my recent code files: bit.ly/16U2K3b \$\endgroup\$ – Alex Netkachov Nov 2 '13 at 0:52
  • \$\begingroup\$ I actually afraid of mixins because this approach looks similar to multiple inheritance, which almost always is not a good idea. I cannot remember any situation when they will be an any use (maybe I just to not know them good enough to use them or never have to). \$\endgroup\$ – Alex Netkachov Nov 2 '13 at 0:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.