(and prototypal inheritance aka OLOO — Objects Linking to Other Objects)
Constructors violate the open/closed principle because they couple all callers to the details of how your object gets instantiated. Making an HTML5 game? Want to change from new object instances to use object pools so you can recycle objects and stop the garbage collector from trashing your frame rate? Too bad. You’ll either break all the callers, or you’ll end up with a hobbled factory function.
If you return an arbitrary object from a constructor function, it will break your prototype links, and the
this keyword will no longer be bound to the new object instance in the constructor.
It’s also less flexible than a real factory function because you can’t use
this at all in the factory;
If a caller forgets
new and you’re not using strict mode or ES6 classes [sigh], anything you assign to
this will pollute the global namespace.
Factory functions are simply constructor functions
minus global pollution danger
minus awkward limitations (including that annoying initial capitalized letter convention).
Object.create(), we have everything we need — with none of the mess.
“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” ~ Joe Armstrong
The coupling between a child class and its parent is the tightest form of coupling in OO design. That’s the opposite of reusable, modular code.
the duplication by necessity problem
ES6 classes don’t fix any of these problems. ES6 makes them worse, because these bad ideas will be officially blessed by the spec, and written about in a thousand books and blog posts.
These problems have a multiplying effect as your application grows
Stampit isn’t the only alternative, of course. Douglas Crockford doesn’t use
this at all, instead opting for an entirely functional approach to code reuse.
simply cloning objects by copying properties from a source object to a new object (e.g.
The copy mechanism is another form of prototypal inheritance. Sources of clone properties are a specific kind of prototype called exemplar prototypes, and cloning an exemplar prototype is known as concatenative inheritance.
The seminal “Design Patterns” book by the Gang of Four is built around two foundational principles:
“Program to an interface, not an implementation,” and
“favor object composition over class inheritance.”
new considered harmful
inheritance considered harmful
super is a code smell
Douglas Crockford got Object.create() added to the language so he wouldn’t have to use
Kyle Simpson coined the term OLOO (Objects Linked to Other Objects) to clarify the distinction between prototype delegation and class inheritance.
Classical Inheritance is Obsolete - How to Think in Prototypal OO on Vimeo
How not to do inheritance.
Child needs to know about implementation of parent class.
Prototype is just working sample.
Three kinds of prototypes.
Delegating property lookup to another object.
Flyweights object for free
Cloning / concatenation
Existing sample object can be copied.
Great for mixing or default state.
Not really type of prototype, but can be used like that
For data privacy and encapsulation.
Example of these techniques - StampIt.
Slay'n the Waste Monster by Colt McAnlis (#perfmatters at SFHTML5) - YouTube
JS Objects: Inherited a Mess
embracing that JS has "behavior delegation" (merely delegation links between objects) fits naturally with how JS syntax works, which creates more sensible code without the need of helpers.
One of the most common metaphors used in traditional class/inheritance OO is that the class represents a "blueprint" for a house to be built, but once you instantiate that class, you are basically copying all the characteristics from the blueprint into the actual built house.