Part 1: Prototypes vs. classes

▤ Summary

There’s a quote that’s been repeated so often that it’s become a software engineering aphorism, or even axiom: This exhortation does of course originate from the (in)famous Gang of Four’s book Design Patterns, but despite its widespread recognition, the actual observance of it is often curiously lacking in concrete projects and implementations. Let’s illustrate with a common form of example which I bet many will recognize (see the next article in the series for a more detailed account of the ES6 class syntax): All perfectly well and good, with the expected prototype chains in place. But, before you know it, it has somehow grown absolutely imperative to also handle centaurs, which share characteristics from both and , thereby not fitting into the neat hierarchy that has been running smoothly in production for a good while (and therefore cannot be changed without creating havoc). Here it should be noted that there are certain caveats to using in this way depending on the nature of the exemplar prototype(s) involved, and you may have to resort to more verbose calls for a more robust mixin implementation, but for simple cases like this it is perfectly adequate. That sort of thing is, of course, precisely what principles such as SOLID are all about avoiding, but it is perfectly possible to paint yourself into corners anyway simply as a result of the tight coupling arising from the inheritance model (the circle-ellipse problem is a classic example).

▦ Linked Companies

CodePen

$1M to $5M