Luke Smith: Class Inheritance and Composition Patterns in YUI

>> LUKE SMITH: If any of you have given presentations before, you know that having twice as many
slides as you have minutes is a bad idea. Yeah, this is going to be fun.
All right. My name is Luke Smith, I'm one of the core developers on the YUI team, and
we're going to be talking about inheritance patterns. We're running a little bit late
so it's going to go fast. Hopefully I won't be speaking too quickly to melt any brains.
Let's go.
By way of introduction, here we are again: browser wars. It's a lot of old news again.
It's different now than it was before. We have new browsers that are better. Old browsers
in the old days, they sucked, the hardware was terrible. Now we have more devices and
it's generally hard to be a developer; that's not new. But the context of what makes it
hard today is definitely different than it used to be.
But one thing that hasn't changed from the old days to now, and even the time in between
that, is time. It continues to be rare that we are given enough time as developers to
build out our applications in such a way that we are meeting all of the requirements of
accessibility, internationalization, and really future proofing the code that we're writing
so that it ends up not costing us time over the life of the application in the maintenance
cycle. Time does break down into that basic division here between the time spent upfront
building the thing, and then the time spent over the life of the application that you're
syncing into feature enhancements, bug fixing, and my God, I can't believe I wrote that code.
The development time is really where you put in the investment to reduce the maintenance
time. Development time breaks down into two basic sweeping generalized categories of prototyping
and structuring. Prototyping is where you just get the thing working, right? If you've
done any hack days, that's all it is. But you are hating your future you if you stop
with prototyping and push to production. You have to put your code into some sort of structure,
creating those relationships between the objects in your system, properly modeling the objects
in your system, and organizing them in such a way that over the life of the application
if something comes up, you know where to look. Or things are isolated well enough and combined
in such a way that it's trivial to update and maintain over the life of the application.
So structuring is where the investment really happens.
That's obviously what this talk is about, so let's get into it. YUI comes with a lot
of stuff for creating infrastructure out of the box and getting that rough framework for
you to put your application in. We have the CSS, we have the modules, and loading, and
the custom events for doing more decoupled relationships between objects. But we have
to build classes on top of those things and work with other objects on top of those things,
and there are a lot of different ways that we can create the relationships between those
objects; the types of patterns that we can fit those relationships into.
I have a lot of different strategies to cover, and I'm going to start with the two native
styles of inheritance relationships and then go on to the artificial relationships that
we build into the library. We have methods for making it more convenient to use the native
inheritance styles, and then when we start getting into the artificial structures, that's
when, in my opinion, you get a lot of payoff for your maintenance going into the future.
Starting with native, pseudo-classical. This is old school, everybody's done this, right?
I mean, there can't be anybody in the room that hasn't written this back in the day,
creating a superclass to subclass relationship by just assigning the prototype of the subclass
with an instance of the superclass. If you've done this before, you should probably know
why this is bad. But we've had the extend method in the library since the first versions
of YUI2. You see this pattern used in libraries everywhere, and outside of libraries. There
are a lot of versions of an extend method, and this one is ours.
If you just take this one line and replace it with Y.extend, it's already better. We'll
go over why it's already better in just a second. The extend method adds that extra
sugar of saying OK, we know that you're planning on creating a relationship between one class
and another class so we'll add in some additional arguments to allow you to define the class
as well. The third parameter to extend, for example, is where you can add in your prototype
properties. There's a subtle difference between doing this and doing individual prototype
assignment or just saying subclass.prototype equals some object literal.
Then a lot of people don't actually know that there is a fourth argument to extend, which
takes the static properties that you want to decorate your subclass as static methods
or static properties. This actually comes in handy largely when we start extending the
infrastructure pieces in the library, like Base, or widget.
But then there's one other little trick with extend, which is that it returns the subclass
that you pass in. You don't have to define the subclass first and then call extend, you
can actually use extend as a class definition method if you want. You're just passing in
the constructor function as the first argument to extend, and it'll return that. Then you
capture the return value of extend and boom, you have your subclass with your constructor
with your extension relationship, your instance members, your prototype, and your static properties.
OK?
We're going through extend kind of quickly because everybody's used basic extend. It
is the meat and potatoes of class relationships, subclass-superclass relationships in JavaScript.
It is using prototypes, so it preserves instanceof, and it's very bare bones, and it's fast. Extend
also adds that static superclass property so that you have access to overridden methods
if you need. We'll talk about why the control of the superclass constructor execution is
actually a benefit when we start talking about some of the other techniques.
The cons for extend are really relative to the other methods of creating relationships.
For example, there's no multiple inheritance because inheritance goes through the prototype
chain and the prototype chain is linear; it does not fork. The constructor chaining is...
while you have control of when and where it happens, it is kind of awkward to do. It tends
to look like this, and I'm sure everyone here has memorized this and typed this out. I mean,
you can prattle it off by memory. No, because it's kind of awkward, right? It's really long
and idiomatic.
And if the superclass that you're creating a subclass of doesn't actually represent a
set of functionality that's going to be used heavily by the subclass, or by the instances
- if the instances aren't going to be called with the superclass methods directly - then
maybe the subclass superclass relationship, isn't the right relationship for that. You
might actually be incurring a cost for calling the superclass constructor if you're not going
to be using those methods. We'll talk about different methods to avoid constructor chaining
in the superclass, or establishing different relationships for your subclass-superclass
and other types of features.
To sum up, it's good for the basics. But if you can use Y.Base - and I will mention this
again - use Y.Base, because there are a lot more options for you. It brings so much more
to the table in terms of not only feature set for the classes that you have but also
for the structure that you can establish on top of those classes, or to even assemble
those classes.
Now let's take a side jump through prototypal inheritance. I have probably more slides in
here than I should. This is a bit of an aside and we're going to take this aside by a route
through the extend method itself.
From time to time we get questions about why YUI doesn't use prototypal inheritance and
instead uses pseudo-classical inheritance, and the answer is, well, we kind of do, but
for most modern web applications, pseudo-classical inheritance makes more sense, and I'll actually
show you an example of why. Inside of extend, here you see we're calling the Y.Object method,
and the Y.Object method is the method for establishing a prototype relationship. Doing
prototypal inheritance, it all goes through Y.Object; you don't have a lot of options
there. That's where it comes from.
This is it. That's the method. If you are on a browser that is ES5 compliant, it has
the Object.create method so it's even smaller than that actually - it just calls object.create.
But in essence, it does just this. It actually is less complicated than what it looks like
here. There's a little magic with the anonymous function wrapper and the private function
F there. You can think about the Y.Object method being just these two lines here, where
you're setting the prototype and then you're returning a new instance of F.
How does that work in comparison with the new superclass method of old? If we had a
superclass that we wanted to assign into the prototype slot for the subclass, calling the
constructor is bad. We just want to establish an inheritance relationship between these
two classes - we don't need an instance to represent anything, we just want to have all
of the methods on the prototype of my subclass and have that instanceof relationship established
between those two classes. Calling the constructor is actually a cost. Also, you might have to
pass something to the constructor in order for it to do something. It might just break
if you don't pass arguments to the superclass constructor. But what are you going to put?
I mean, you're just trying to establish your relationship.
What Y.Object does in this, if we walk through it, is since the constructor is what's creating
that cost, we avoid it by taking the prototype object and copying it over into this empty
function here and then creating an instance of that. Since the constructor for this is
empty, it doesn't do anything, there's no cost. But because this prototype here was
the same object as that prototype here, when we create an instance of this we do maintain
that instanceof relationship. But there's still a cost here, and that is that the superclass
constructor is not called when you create an instanceof subclass. It's not called automatically,
ergo the need to manually call the superclass constructor to chain those constructors, and
that big long awkward thingamajig.
But if you want to just do pure prototypal inheritance, then just using Y.Object you
don't have to be working with a prototype of some other class, you can just be working
with any old object. You pass it into the prototype there and boom, you create an instance
that has all of the properties of that object through its prototype relationship. You don't
have to copy over individual properties, you just get them for free. Plus if you modify
that object then those show up for everything that inherits through the prototypal inheritance
for all instances that are begat from Y.Object.
But in practice it doesn't have an awful lot of use because the fact that the properties
of this object aren't own properties of the instance, they live on the prototype, means
that you can't enumerate over them for example. If you want to do an enumeration with hasOwnProperty,
all of those properties on the prototype are going to return false. That actually can get
in the way in terms of common patterns of code use where you're just going to be iterating
over the properties of an object.
One pattern that is useful for using Y.Object and the prototypal relationship is the factory
constructor pattern. If you follow along what's going on here, I'm defining a class set and
instead of working with the "this" object I'm going to be working with the "that" object.
I assign the "that" object dynamically based on what this is inside of the function.
I'll show you an example of why this matters. If I call a new set, then inside of my constructor
the "this" object is going to be an instanceof Set. So instanceof Set is true, right? But
oops, I've forgotten new. That means that the "this" object inside of the Set constructor
is going to be the global object. We really don't want to be modifying the global object
in our constructor. Using Y.Object, we'll do what we did for the extend relationship
-- do you remember the extend relationship? We took a Y.Object of the prototype of the
superclass and basically what that does is it creates an uninitialized instance of that
superclass. In this case, we're going to create an uninitialized instance of the very class
that we're inside of. Incidentally, we're in the constructor so we're going to then
continue on with initializing it. As long as we remember to return the "that" object
instead of the "this" object then we're all good. What comes out the other side will also
be an instanceof Set.
That's one way that you can cover your butt a little bit, or give your users the opportunity
to fail but not have it result in a code failure, using the factory constructor. The YUI class
itself actually does this as well, so that's why you say "YUI()" -- that's effectively
saying "new YUI()".
OK. Enough time in prototypal inheritance. The relative pros and cons are... Like I said,
it avoids copying properties. Because you have all of these properties hanging out in
the prototype, that means if you assign a property to that object it can shadow one
of those properties in the prototype. But if you then delete the property, it hasn't
deleted it from the prototype. You can create a sort of "here's my original values, I'm
going to create an instance derived from that and then I'm going to update it, but then
I can revert to the original values by simply deleting those properties and letting the
prototype properties shine through."
You can use the factory constructors if you want. In practice, the avoiding class explosion...
I haven't seen it be a perfect fit for that, myself.
The cons are a short list but they are fairly significant. You don't get the multiple inheritance
which is because it's going through the prototype chain. The factory constructor is nice, but
it is effectively dead code if people are using new like they should be. You're adding
code to protect against the improper use of your code. Then the hasOwnProperty gets in
the way really quick, let me tell you. I've done some prototypal inheritance based code,
and the fact that I can't do a hasOwnProperty any more, it just feels sort of exposed and
uncomfortable. It's so easy for me to just automatically type that hasOwnProperty in
there that I'll add a bug by just mechanical typing.
It doesn't really fit in with a lot of the problems in web development today. What I've
found, at least in patterns that I've seen for use of prototypal inheritance, is that
this tends to emerge. We'll take this prototype object and we'll beget a few instances of
it, but whenever we beget instances of it we're always going to be updating those instances
to differentiate them from the prototype itself. But when you're differentiating it from the
prototype itself, you're usually doing it in the same way, which is a constructor.
Here we are again, back in the pseudo-classical inheritance pattern. Now let's move on.
That was the native methods. Now let's get into the fun stuff, which is when we start
creating artificial relationships between stuff that will throw instanceof under the
bus. instanceof... I don't care about instanceof.
The first is going to be augmentation. Augmentation is the first approach that I'm talking about
now for creating a multiple inheritance relationship. The key API in question is Y.augment. You
can see Y.augment being used in a few places in the library if you course through the code,
which I recommend, incidentally. In particular, ModelList is an example here, where we have
the ModelList being defined by its constructor. You can see that it's actually extending Base.
Its extension hierarchy is already taken, so we can't extend arrayList also. We have
already extended Base. Instead what we'll do is we'll augment arrayList.
What this does is it takes the ModelList class as it exists right now, as a Base subclass...
You can see here, we have a constructor for ModelList which is chaining into the constructor
for Base, we have some Base methods and we have some ModelList methods in the prototype.
Then what the augment does is instead of just mixing the methods directly under the prototype
and then creating some relationship to the constructor -- I wouldn't know how you could
do that really easily anyway in pure JavaScript - instead what we're doing is we're defining
the sort of placeholders of these activation functions on the prototype, which map to the
names of the APIs on the prototype of the augmenting class. When we create an instance
of ModelList we're only calling the constructor for ModelList, which then chains to Base,
and boom, we have an instance. The instance inherits the prototype, which has these activation
methods.
Now, if we call each on this instance, it's going to then fall over to the prototype's
implementation of each, which is then going to send this activation signal through the
augment infrastructure to do three things. The first thing it does is it copies over
the individual methods from the arrayList prototype directly onto the instance. Then
it calls the constructor, so now we have the instance here having gone through the appropriate
set up to make it work as an arrayList. It has the methods and it has gone through initialization.
Then finally we call that method again on the instance, which now is the version of
the method from the arrayList prototype.
It's kind of complicated and convoluted, and it only gives you limited control of... Here,
let's go through this fancy animation one more time. When we call the constructor here,
how did we know what we were calling it with? Because we created an instance of ModelList
earlier and we were passing arguments into that constructor, but the arrayList contructor
was called automatically for us so we didn't get input into what we could pass into that
constructor.
Augment does support limited configuration into what you can pass in with the fifth argument.
I'm not actually going to talk about the third and fourth, because in practice they're not
very useful, but the last argument to augment is the argument that you would pass in to
the constructor of your augmenting class. It's good that you have some control into
what goes into that constructor - it's less than excellent that you only get to define
it once. There's no instance level control. That goes into the pros and cons.
If you're with me here, the augment interaction and setting up the relationship between one
class and the augmenting class is kind of complicated. It's a little intricate. The
challenging part, really, is establishing a relationship of a class that already has
some extensions, or that already extends from a superclass. How and when do you trigger
the superclass constructor?
What augment aims to do is it targets a situation where the class that you're adding the behavior
onto your class with... You have multiple inheritance, so these class behaviors are
maybe less useful and maybe aren't going to be called very much, but in going through
the constructor there's going to be some set up costs for them, so you don't want to incur
that cost on all of your instances unless you have some signal from the implementation
that they are going to be used. It defers the constructor of the augmenting class. It's
a special kind of lazy multiple inheritance, basically.
Because it is multiple inheritance, that is a pro. Now we're able to do multiple inheritance.
You give up instanceof and you've given up the static link to the superclass, because
now we're relating to multiple classes.
This is also low level, like Y.extend is low level. You can just do this with any function
that you want to. Augment handles this at a lower level.
The cons for augment are also perhaps pretty obvious, actually. The first call to one of
those augmenting methods is costly. The call to the constructor is basically a wash. You're
either going to do that in your subclass constructor, chained to the augmenting classes constructor,
or when it gets triggered by that augmented method to call the constructor and then call
again to that method, that's basically a wash for doing the call to the constructor. The
cost is that we are creating copies of the functions... We're copying all of the individual
functions from that augmenting class onto each instance, and that's going to consume
memory and it consumes time. You have to ask yourself really if the value of the deferred
constructor is worth the potential cost in memory and the initial hit that you'll take
with that first call to one of the augmenting methods.
Also, because we get into multiple inheritances we have to worry about the diamond problem,
where you have subclasses inherit from multiple superclasses, and those superclasses inherit
from a common superclass themselves. You end up going through a superclass hierarchy and
then duplicating some grandfather constructor logic which often messes things up.
OK. To sum up, you can use augment or you can just use this sort of pattern here, which
doesn't defer the superclass constructor but just inlines it into the constructor of the
subclass, just like it does with the superclass. For the prototype that you define for your
subclass, you just create your prototype as it is and then mix in the prototype of the
additional augmenting class. In this case, the prototype contains direct links to the
prototype methods automatically; there's no copying of instance methods or copying of
class methods over to instances. Everything exists in the prototype. You are taking the
hit in the constructor for the other class in your subclass constructor. If that's fine,
then this will likely end up being a faster multiple inheritance strategy as opposed to
using augment. Use augment if deferral of that constructor is really important.
Now let's get into two of the really fun things, which are plugins and class extensions. Now
we start to get into really flexible structures here. Plugins are... I guess I'm forecasting
a bit, but plugins you can think about being instance based, class extensions you can think
about being class based. The operative method in plugins is the plug method, and the plug
method is something that is on the host. The plugins themselves have very, very few requirements,
and we'll talk about that in a second.
If we walk through what happens here, we have the overlay class which is a Base-derived
class, which means it has plug. In order to plug something in, the class that you're plugging
it into needs to either extend or be augmented with, or just have, the APIs for Y.Plugin.Host.
Base gets that for free. Nodes also get that for free too, so you can plug in Nodes, which
is pretty awesome. We'll create an instance of overlay, so now we have these attributes
on this instance of overlay here, and now we introduce this plugin drag class, which
exists in the library. When you call plug, what it does is it calls the constructor and
creates an instance where it's passing in the overlay instance as part of the configuration
passed into the constructor. But really this is just an instance of a class.
We basically have two objects at this point, two objects that each have their own respective
set of attributes, that each have their own respective prototypes. It just happens to
be that the instance of this plugin is coded in such a way that it takes that host configuration
and it wires itself into that host to listen to its behaviors, to listen to its events,
and maybe add some advice through AOP methods, Y.Do.before, Do.after, and some other sugar
methods that actually are available on Y.Plugin.Base. Then it takes the namespace that is configured
on that plugin and it just assigns a new property on the instance of overlay here, called dd,
that points directly to this instance. Basically, at the end of the day, we've created two objects
and then we've assigned one object to the property of another.
That means that overlay.dd is a separate object that just knows about overlay and it works
with overlay. It's kind of wired into it. But it does maintain its own stuff. If you
need to set one of its properties then instead of setting a property on overlay, you're going
to be setting a property on that other instance, the drag plugin instance. I love the flames.
When you unplug, though, the relationships and any wiring that went into that class goes
away, and that's part of the contract for plugins that we'll talk about in just a second.
The requirements for plugins are that. That's it. The host has to have the functionality
of Y.Plugin.Host, as I mentioned, and all the plugin class needs is a static NS property.
It can do anything it wants; as long as there's a static NS property on that function, it'll
work as a plugin.
[audience member raises hand offscreen]
Ask later, man.
>> AUDIENCE MEMBER: OK.
>> LUKE SMITH: The plug method, as you can see here on PluginHost, basically boils down
to this conditional here: if the plugin is there and it has an NS, then create a new
instance of that plugin and assign it to that namespace. Everything that happens inside
of that constructor, it's up to you. At the end of the day, we end up with the dd instance
here, or the drag plugin instance here with its own set of APIs. Then you can unplug it.
You can actually unplug it by namespace as well.
The contract is where we start to get into the relative pros and cons of plugins, in
my opinion. That is, plugins should expect to be working with the host object, right?
Otherwise they're just sort of vestigial functionality that doesn't care about where it's hosted.
It being a plugin, it should really care about its host. That's not too much to ask, I would
say.
They can provide their own APIs. They could just be a plugin that you add to a host and
it just modifies the behavior of the host, it doesn't add its own API at all. But you
can provide your own API. You can either provide your own stuff or you can modify the host.
There are two things that it must do and it must not do. It has to remove all traces when
it's unplugged, so you can't permanently alter the host object. You have to make sure that
everything you do to the host can be undone cleanly. You can't modify the host directly
- you have to provide your API on your own instance, on the plugin instance itself, which
means that that API is namespaced. So don't modify the host object, just listen to its
events, listen to its methods using AOP advice methods.
Some people don't know that you can actually plug a class. What this does is it makes it
so that when you create an instance of overlay, it is automatically then plugged in with the drag plugin, because you've plugged
in the class with plugin.drag. You can think about this actually as similar to the DOM.
You have an element having a style property, which has its own API. It has its own properties
and that is not duplicated on the element itself. This is auxiliary functionality that
is related to this element, but it is not part of the core behavior of that element.
This is additional functionality, and that's the distinction for going inheritance versus
going plugins or extensions. Well, mostly going plugins. You have core behavior established
through the prototype and through extends, and then you have additional behavior through
plugins.
Let's get into the pros and cons. If you start mixing in a bunch of classes into the same
host class or the same subclass then you can run into naming conflicts pretty quickly,
especially if you're going to be using common verbs for taking actions. So having things
namespaced helps prevent that naming collision.
The ability to plug classes or instances is pretty nice because it adds a high degree
of flexibility. The very few number of requirements that it takes to be a plugin adds a lot of
flexibility. The fact that you can work with Nodes adds a tremendous amount of flexibility,
because you can use Node plugins to be like mini widgets. Or if you don't need to do a
lot of complex state management, you just want to enhance a Node, then you can just
write a Node plugin that does all of that. Maybe over time you might want to evolve that
into a widget, but even if you do that, you can evolve that code into a widget and then
keep a Node plugin that just creates an instance of that widget plugged into that Node. Node
plugins afford you the ability to code from an instance related to a Node, or from a Node
that is augmented with this behavior. It allows you to code in either direction, whichever
your preference.
The cons for using plugins. Cons are always relative, right? It fragments the API, but
maybe you think that this function is kind of core, or it's just kind of a nuisance to
be having to set attributes on a namespace thing. It's just confusing to... I just want
to set the attribute on my overlay, I don't want to set the attribute on some property
of my overlay. It ends up looking odd in the code, or maybe that just feels awkward to
you. Maybe it actually feels right. Totally a stylistic choice. But there is an opportunity
for confusion there for future developers that are then maintaining your code. That's
why I listed it in cons, but again, it's relative.
For the plugin contract to be non-invasive on the host, that can be a little costly.
It also means that if you have multiple plugins then they can start stepping on each other's
toes, and you have to balance out which plugin comes first. If I have a plugin that actually
requires another plugin to be on there as well then those relationships can start getting
a little complicated.
Finally, plug. This is a temporary problem. I think we're going to make plug a little
sugary, or a little easier to use than passing in the class that you intend to plug in.
So yeah, plugins are terribly flexible. They tend to be better in small numbers, at least
in my opinion. When you ask yourself if you want to use plugins or augmentation or multiple
inheritance via mixing into the prototype and chaining all of the superclass constructors,
it becomes a question of do you want to use augment to defer the constructor? Would the
behavior be more likely to be expected directly on the instance? And some other notes that
I can't remember now. Choosing plugins versus augmentation largely boils down to personal
preference: do you want to be adding onto the API of this class, or do you want to be
segmenting this functionality?
For both plugins and augmentation, having the auxiliary code live in its own module,
or live in its own class, has value for maintenance going down the road. Again, we're talking
about the breaking up of one monolithic set of functionality into a series of more discrete
bits of functionality and then creating the relationships there.
Now we get into class extensions, which in my opinion are awesome. Let's get into that.
Class extensions do require Base. We're going to look at the two methods that are used with
class extensions by way of comparing it to the extend method.
In a typical case where you're extending Base, your constructor function does nothing but
pass off to the Base constructor. We saw enough of this in the library when we were doing
this in creating our own classes that we just said let's get rid of that. We need a name
to satisfy the contract for Base, but we're just going to be chaining the superclass,
so let's get rid of that awkward superclass chaining and then we'll add in this additional
argument here which is where the magic happens. With that, we have Y.Base.create.
Y.Base.create you will see all over the place in the library. We love this method. Actually,
we love this method because we haven't made another method that might be a little sexier,
but it does what we need it to do. We'll take a look at an example of a class generated
with Base.create.
The charts packages. There are a lot of individual classes in the charts package that take heavy
advantage of the class extensions. Here we have the line series which is extending Cartesian
series, and Cartesian series is an extension of Base. Here we have, in effect, an abstract
class, called Cartesian series. We're going to satisfy the contract of that abstract class
by mixing in this common functionality Y.Lines, and then gluing the Y.Lines code into the
Cartesian series code. The Y.Lines code is actually useful in other subclasses of Cartesian
series as well, and it might actually be useful outside of the Cartesian series family in
other classes as well.
You can see here, we'll just add this behavior and this behavior and these sets of behaviors
and then we'll glue them together. Since we have some common APIs and some common functionality,
it makes logical sense for maintainability to take that code and put it somewhere and
then incorporate that code. We don't have to do it using a build step, we can do it
using the APIs when you're defining your class. Let's take a look at the process of defining
line series and what it actually does, what Base.create does.
Base.create is going to create this sort of shell of a class, and its constructor is composed
of the chaining of its constructor and all of its class extension constructors. If I
had lines, or fills, or anything else in here, this constructor is going to be a call to
the Cartesian constructor followed by a lines constructor, fills constructor, all of those.
It goes through all of those constructors. In practice, class extensions tend not to
have any logic in their constructor. Prior to 3.4.1, they would because we didn't support
initializer chaining. As of 3.4.1, if you have an initializer defined on your class
extension, it will be chained in, which is really handy because initializer executes
after all of the attributes are set up.
Speaking of attributes, the next step is that it takes the attributes from Cartesian and
any attributes that you've specified in Y.Base as that fifth argument in the ATTRS collection
in there, and then all of the class extensions, and it just mixes them together into one object,
because this is a static collection of attributes. It does some friendly stuff in here in that
it takes the Cartesian and then here, since we actually had a type defined in both Cartesian
and in here, it's just going to mix them together. It combines the configuration for those attributes,
so you're not just clobbering that one with this one. It's not last one in wins - you
can contribute more and more to the attribute with other extensions. This can bite you,
but in practice this has actually been more handy than harmful to us. It's kind of a push.
Finally we get into the prototypes, where it does a similar thing of mixing in the individual
prototypes, starting by creating an instance of Cartesians. We have that prototype relationship
to its superclass, so officially it is still an instance of Cartesian, but all of the class
extensions are then mixed into the prototype directly. Like that alternate solution for
augment where we're just composing the prototype using all of the methods instead of doing
the lazy method linking, all of the instances of line series are going to benefit by having
all of its methods exist already on its prototype.
There's the special affordance then given to initializer, and also to destructor, that
if you define them in the class extensions then the prototype version of this Base.created
class is going to chain all of those initializers together.
When you create an instance of the line series, the three things that it does at construction
time are that it chains the constructors, it sets up the attributes, and then it calls
the initializers in order. It calls the initializers starting with the line series initializer,
followed by Y.Lines initializer, followed by all the other class extensions and initializers.
Class extensions basically break down into two categories: decoration and core functionality.
They're used for different purposes, basically. Class decoration would be if the core functionality
of this particular class is already well defined, instead of going with a plugin model I would
like these APIs and these attributes to exist on class instances directly. I'm choosing
to augment the prototype and augment the attribute collection directly for all instances of this
class. I prefer that for things that aren't going to get too big, or that aren't going
into systems that are needing a lot of plugins and a lot of features, because it's easier
to work with objects that have their own attributes and have their own methods.
The other way is to fill in core functionality. Remember I was mentioning earlier about the
Cartesian series basically being an abstract class? That's where this comes in. We're going
to satisfy the abstract class implementation.
The reason that having class extensions for core functionality is terribly useful is because it promotes
flexibility for an environment driven implementation. YUI has conditional loading of modules, for
example. You can create a class that is composed of a base abstract class followed by a number
of class extensions, and one of those class extensions could be the implementation specific
details of what it means to run in a Node.JS environment. Or I'm going to be delivering
this out to a mobile environment, so I want to have some lighter weight stuff going in
there. I can use dynamic loading to say in this case, in this environment, I'm going
to satisfy the abstract class with this particular implementation, and in the other case I'm
going to satisfy it with the other implementation.
At the end of the day, you have the abstract class and you have smaller bits of environment
specific code that are appropriate for you to be maintaining, because you know that I
have to change something for this class in this environment, so you can segment it out
per environment that way.
This is overlay. We like to show off overlay because this is all of overlay, and we just
think that's really cool. I'm actually curious what your response would be, but we are running
a little bit low on time. This is actually an implementation of all decorators. All of
these class extensions are generically useful to any widget. There was actually some discussion
about whether or not we should bother creating an overlay class, because people can just
create their own instance of whatever overlay-like class they want that's composed of whichever
pieces of this functionality they want, which is still true. You can still do that by, I
think, Panel and Tooltip and other examples that'll just use a couple of those bits of
functionality. These are all features, these are all decoration. This isn't core functionality
to overlay. Core functionality in overlay is just widget.
Contrast that with Slider. I failed to mention the other method for working with class extensions.
Here we have a SliderBase which is an abstract class which we satisfy with that Y.Slider
value range implementation for adding the value attribute, and for tying the movement
of the thumb to updating the value attribute. But it would be awkward to have that functionality
live on a namespace like in a plugin, right? So it defines the class.
But then Y.Base.mix is the method that we can then say here's some additional behavior,
and today I'm going to add this to my class. This actually modifies Y.Slider, and it adds
the behavior onto the prototype, and it updates the constructor and the construction logic
to now include the clickable rail constructor into the constructor chaining, and the initializer
into the initializer chaining. It mixes in the attributes and all of that. So basically
we are dynamically changing and enhancing this Slider class at run time. You can get
into all sorts of fun when you have packaged up features and are adding them into a class
and making it more feature rich, I guess.
The extension pros and cons. I went over this already, but it strongly encourages the segmentation
of code into implementation specific stuff. In particular, it's well suited for dynamically
reacting to environments. If you prefer the APIs live on that class for features then
it's a good option. Otherwise, for doing the abstract class pattern, you would want to
be using class extensions for that.
Because of the nature of the class extensions being aggregated onto that class, it allows
you to emulate other patterns for assembling your class together. If you want to emulate
an MVC breakdown in the logic for your widget, for example, you can have the class extension
that does the model stuff, you can have the class extension that does the view stuff,
you can have the class extension that does the controller stuff, and then they are Base.created
onto a class. You then instantiate it, and it has all of the logic and the APIs there
in one object. You use that one object instead of working with three disparate objects.
The cons. It saying that it requires Y.Base is a con bothers me. I really like Y.Base.
There is some initialization overhead, because it is going through all of the chaining of
the constructors, the chaining of the initializers. And you can't do this to instances like you
can do with plugins. It doesn't work on Nodes. And other things that we talked about with
augment where you're going to run into naming collisions.
I think the big takeaway, really, from the session should be: look at extensions and
plugins, play around with them, see what feels best for you and your particular style. If
you want to use class-based plugins so that all instances have this additional feature
set, but that feature set exists in a namespace like it does in patterning after the DOM...
In particular, look at class extensions for doing class composition for segmenting out
reusable bits of code.
Yeah, I think that's largely it.
MVC. Since we are out of time, and since Eric is doing a talk on MVC tomorrow, I am going
to forgo all of my slides and say go see Eric's talk because he knows more about it, because
he wrote it.
[applause]
Wait! Use Base. If you don't know about the IRC channel, we're in there all the time.
Great community in there. All right.