Extends v. Implements
You would extend Events if you were creating something that *is an* event,
rather than creating something that *has* events.
That's the easiest way for me to describe the difference. Back to Aaron
Newton's talk "programming to patterns" ninja example:
var Ninja = new Class({
Extends: Human,
Implements: Sword
});
A ninja *is a* human, and *has a* sword.
MilkBox could possibly be an extension of Fx.Morph, or just Fx, but never an
extension of events.
Practical differences:
- Extends gets `this.parent` in the methods to call the super method. (as
mentioned already)
- You can use `Implements` to copy over stuff from multiple objects (as
mentioned already)
- Changing the prototype of the parent class will automatically change your
extends sub-classes
Singletons
There's Christoph's Class.Singleton, I've never used it though:
http://github.com/cpojer/mootools-class-extras
Also, you can do `var MilkBox = new new Class({})` which runs the object
through the Class generator, then immediately creates an instance. I don't
really like when classes do this though because it makes extending them
possible only through "normal" JavaScript patterns.
On Nov 2, 2010, at 3:58 AM, stratboy wrote:
> Hi! I'm currently redesigning my plugin (Milkbox), based on Mootools
> 1.3, and as I do it, I want to be sure to clean up code and use best
> practices.
>
> So a couple of questions:
>
> 1. What are, apart from the main one (the modification of prototype),
> the practical differences of extending vs implenting Events? For
> Milkbox, I just need to fire some simple event to listeners. Till now,
> I always did it via Implement. Is it the best way?
>
> 2. Milkbox is not supposed to be instantiated more than once per page,
> since there's no reason to build the viewer's html code more than
> once. Instead there can be a lot of different galleries, and all use
> the same viewer (so maybe I could code a MilkboxGallery class)..
> Anyway, that said, if I want to prevent instantiation, should I use
> some kind of singleton or is it better to simply put some arbitrary
> internal check? Or maybe there's some other better pattern?
>
> Bye (and thanks)!
>
>
>
>
>
