Extensible coding with Mootools makes me feel good in a way.

So when I started my latest project, every time I wanted to do something, I thought about whether I could put my code into a class or an element extension. Sure enough, nearly all of my code was reusable and I simply hadn’t been taking the time to put it into a reusable form. I’d been reusing functions within site applications, but hadn’t been thinking about how things could be reused between sites. My current project is small, but just making this small change in my thinking has drastically cut the main code base and dramatically increased the code organization (which I honestly thought was pretty good before).

I don’t know if anyone else has similar tendencies, but it’s amazing how much more strict I am about organization when building a class. Maybe it’s just me, but as soon as I turn something into a class I have the overwhelming urge to break it down into as many discrete functions as possible. So not only have I produced a lot of reusable code, but the quality of that code is much better than it would have been otherwise.

Thanks for sharing your thoughts. I’ll certainly be trying to build things with more of an eye towards reusability from now on.

Regardless, this is all great feedback. Regarding jducoeur’s suggestions on refactoring, I think that your approach is a matter of discipline. I’ve found that if I don’t do this kind of management as I’m writing the code, I don’t tend to get back around to it. Maybe two months later, on a different project, I’ll think “This is just like that thing I did a month or two ago…” and the 5 or 10 or 30 lines of code needed to replicate it don’t merit revisiting that older code.

I’ve found that since I started working this way that things that I would never consider reusable to come around more than I would have guessed, and the fact that they are already portable increases the likelihood that I’ll use it.

I agree with sivoh’s comments about the other value – that it decreases complexity. Or, maybe it’s that the complexity is more defined. You know where the touch points are of the application instead of getting this big spaghetti mess of functions and stand-alone code.

-Aaron

When I’m just writing something for the first time, I’ll simply write it out in-place. But I try to be absolutely strict about never duplicating code. If I find myself writing the same thing again — even just a few lines of code, or sometimes even a single line with complex parameters — then that indicates to me that refactoring may be called for. At that point, I’ll lift that code out into a method, or a separate class/widget if the functionality cuts across class lines.

This approach seems to strike a good balance: rather than trying to guess in advance what is going to be reusable, I keep a close eye on my code and let the reusable bits emerge as I write. That way, I don’t spend too much time on factoring the code excessively, but still avoid code duplication (which is the root of most programming evils).

If you haven’t read it, I commend Martin Fowler’s book “Refactoring”. It’s one of those programming bibles that is worthwhile for every programmer…

I think there’s a typo in your Class.Binds example, it references this.boundAlert, which I believe should be refering to just alert in that last example.

Nice work on releasing the classes, you saved me some time with these :-)