- Classical Inheritance
- Classical Inheritance with helpers
- Prototypal Inheritance
- Prototypal Inheritance with helpers
2. Classical Inheritance
Above I’ve applied the Module Pattern, a perfect way to simulate classes. It is considered a good practice to provide all external dependencies of a class as its arguments (like I’ve done here with jQuery). So, to let class Foo inherit from Bar do
As you can see, it requires some prototype magic, but at the end you have classical inheritance up and running.
3. Classical Inheritance with helpers
All this prototype juggling from the previous section is nice, but if you’re already dealing with complex matter, it will probably not make you more productive. So to simplify classical inheritance, copy the JIL code into your project and the Foo class can be transformed into
(example on jsfiddle)
Unfortunately, the new keyword has two problems. If you omit it by accident, the code is still valid, and the function in question is not called in its god-mode, and the bug-hunt that will follow can take a lot of time. The second issue is that you cannot use any of the functional features like apply or call. The library solves this issue and introduces the $new functions
4. Prototypal Inheritance
The new keyword and the prototype property try to fix the gap between its prototypal nature and classical inheritance, but still this whole implementation feels a little bit clumsy. With prototypal inheritance, a form of object-oriented code reuse, objects are created using other objects:
5. Prototypal Inheritance with helpers
This looks a lot easier than what we saw with Classical Inheritance, but calling overridden methods is still equally painful. Also note that there is no default constructor anymore. The Bar-Foo example from above can be rewritten as follows
If performance is crucial, it will help to define named functions instead of anonymous functions.