OLOO Pattern clarification

Question

I'm still studying but lately changed the field I want to work in to web development. So programming is nothing new to me but I never really looked twice at javascript.

I'm trying to learn fast but I got confused about the different inheritance patterns used in javascript. I looked up on the classical prototype chain where the .prototype reference is set by the programmer (I think this is commonly refered to as prototype pattern). Then I was reading lots of blogs and articles about OLOO and its advantages regarding simplicity.

So I tried coding a little sample myself and while researching for a good approach I came up with a snipped of code that I can't really put into any of those two categories.

I made a fiddle if one wants to have a look: http://jsfiddle.net/HB7LU/19377/

For anyone else, this is basically my code:

function Parent() {
    return {
        array: [],

        add: function(element) {
            this.array.push(element + this.array.length.toString());
        },

        getAll: function() {
            return this.array;
        },
    };
};

function Child() {
    return Object.assign(Parent(), {

        removeAllButOne: function() {
            this.array.splice(1);
        }
    });
};

foo = Parent();
foo.add('foo');

bar = Child();
bar.add('bar');

foo.add('foo');
bar.add('bar');
bar.removeAllButOne();

Hopefully someone can clarify what it is I did here and what drawbacks I'll face using this method. I know it can't be OLOO because OLOO relies on a simple Object.create(...); to create new objects.

EDIT: Link to fiddle was broken, sorry

You link goes to an Angular example. Is that intened? And the missing thing there is the ng-app declaration ;) — kwoxer, Oct 29 '15 at 21:12
The link indeed goes to an AngularJS example, I hope that this will not confuse people. The link should now work as intended, I think there is no ng-app needed because you can not see the whole html document. At least the fiddle I made worked that way. — swent, Oct 29 '15 at 21:17
It is year 2015 outside: you can use javascript classes from ES2015 — zerkms, Oct 29 '15 at 21:18
This question may be helpful... http://stackoverflow.com/questions/29788181/kyle-simpsons-oloo-pattern-vs-prototype-design-pattern — Jeff, Oct 29 '15 at 21:19
Thanks Jeff, but that was one of the texts I've been reading even prior to my problem... and I'm still not sure. — swent, Oct 29 '15 at 21:24
@TimSeguine https://babeljs.io/ there is no reason to not use the modern standard: your code can be ES2015 right now, and when browsers are ready - you just remove transpiler. — zerkms, Oct 29 '15 at 22:09
@zerkms - Except you have to implement a transpile build step and you have to debug with tools that understand map files. Not hard things to do, but not quite as simple as without transpiling. I've personally been a bit surprised how verbose some of the transpiled code is (lots of extra closures created) too. Not sure what impact that has on code size and/or performance and/or memory usage. — jfriend00, Oct 29 '15 at 22:13
@jfriend00 I don't use js source maps at all: the transpiled code looks very close to the original. As of impact: I personally think it's a good trade: to have some overhead today but with a modern codebase that after a year can shine when runs natively, other than to write code from 2000s that will never be converted to convenient es2015/2016. " Except you have to implement a transpile build step" -- you most likely should have a build process anyway. If you don't - you're doing it wrong. — zerkms, Oct 29 '15 at 22:15
@zerkms - Do you really think you'll be ONLY serving ES6 code to web pages in one year? You are way more optimistic about how quickly old browsers die than I. Now, if there was a clean way to automatically serve ES6 code to new browsers and transpiled code to old browsers, that would be cool. It is nice to use ES6 in nodejs development though. — jfriend00, Oct 29 '15 at 22:18
@jfriend00 well, I'm not insisting :-) I'm writing both ES6 and ES7 (for browsers) for more than a year already and I feel amazing :-) If one wants to write ES5.1 forever - it's their decision. — zerkms, Oct 29 '15 at 22:19
@zerkms some people still have to support IE8(still like 8% market share last I checked) and since IE8 doesn't even support ES5, I am a bit skeptical if Babel supports it. Up until a couple days ago the FAQ specifically said IE9+. Now they just don' t mention compatibility at all. My gut says assume it is broken unless there is reason to believe otherwise. For some projects, sure it's fine. But the project owners from small companies tend to complain if their users who are still using windows XP can't use the site. — Tim Seguine, Oct 29 '15 at 22:36
@TimSeguine OP does not look like someone that must support a browser released 6.5 years go. They just learn. And it's weird when instead of learning modern tools one digs into something that just should die and learns hacks instead. But as I mentioned - I'm not insisting. I'm supporting IE>=9 and I'm using ES2016 (yep, that has not even been standardised yet) today. — zerkms, Oct 29 '15 at 22:37
@TimSeguine PS: I just realised the code from the question already uses ES2015, which means there is even less reason to not use proper classes. — zerkms, Oct 29 '15 at 22:42
@zerkms For me, this is about the fact that you said "there is no reason to not use the modern standard". That is not true. Needing to support potentially 8% of your users is a very good reason to not use it. If you don't find that important, I am not going to tell you you are wrong. Not having ES6 (or even ES5) isn't even the most difficult part of supporting IE8, so I have more important things to do than to try to shim and polyfill so that babel might work on IE8 maybe... sometimes... if the moon phase is right. — Tim Seguine, Oct 29 '15 at 23:02

jfriend00 · Accepted Answer · 2015-10-29T21:42:40.800

What you are doing is somewhat like a mixin pattern. You're creating a new Parent object, then partially merging it into the Child object which is kind of the idea behind a mixin.

Here are some references on mixins:

A Fresh Look at Javascript Mixins

The Mixin Pattern

JavaScript Mixins: Beyond Simple Object ExtensionPosted

Here are some disadvantages of what you're doing:

You create a Parent instance, copy from it, then throw it away.
Any methods on Parent.prototype would not be inherited
instanceof Parent will not be supported
instanceof Child will not be supported

Object.assign() only copies enumerable, own properties so it does not copy the entire state of a Parent object, thus it can only be used in this circumstance when you explicitly know the parent object doesn't have any of the things that will not be copied.

Well while reading your answer it all makes sense now. Thanks for your help. This throws another problem for me, but I think I should start a new Question for this? Or is it ok to post a follow-up? — swent, Oct 29 '15 at 21:42

OLOO Pattern clarification

1 Answers1