Inspired by Aaron Newton\’s \”Programming to the Pattern\”

Aaron Newton is a contrbutor to MooTools and the care-taker of Clientside, CNET.com\’s developer blog. He recently wrote about being inspired to write code differently and a more indepth post about his thoughts on (take a deep breath if you\’re verbally reading this) \”jQuery, MooTools, the Ajax Experience, Programming to the Pattern, and What Really Makes One Framework Different From Another\”. He has inspired me to be more aware of how I write my code.

Programming to the Pattern

Aaron\’s says:

When I write my code, I can choose to be an architect, or a construction worker. I can design, or I can implement. In reality, I must do both, but I can choose which one I want to do more and, in many ways, it’s possible for me to do almost entirely one or the other – though not 100%.

What the hell am I talking about? Let me put it to you this way: if you write 20 lines of code to describe a user interaction on a page to make it snazzy or easier to use, is it worth writing another 5 or 10 lines to make that code reusable? If you program the experience directly, you’ll always write it again and again. But if you program the pattern, you’ll write less and less.

This part really got me thinking because I know I don\’t want to keep re-writing code, but that\’s just what I\’ve been doing. I\’ve tried writting my classes to be reuseable, and so have my co-workers, though the only real way to reuse it is to not only copy of the class, but use the same HTML markup as well, which I don\’t really want to do because other people may have different markup.

His code example is a really good one:

var PopupForm = new Class({
	Implements: [Events, Options],
	options: {
		requestOptions: {/*the user can fill in additional ajax options*/},
		onComplete: $empty //do nothing on complete by default
	},
	initialize: function(link, form, popup, options) {
		this.form = $(form);
		this.link = $(link);
		this.popup = $(popup);
		this.setOptions(options);
		this.makeRequest();
		this.attach();
	},
	makeRequest: function(){
		this.request = this.form.retrieve(\'send\', this.options.requestOptions);
		this.request.addEvent(\'complete\', function(response){
			popup.set(\'html\', response);
			this.fireEvent(\'complete\');
		}.bind(this));
	},
	attach: function(){
		this.link.addEvent(\'click\', this.show.bind(this));
		this.form.addEvent(\'submit\', function(e){
			e.stop();
			this.request.send();
		}.bind(this));
	},
	show: function(){
		this.popup.show();
	},
	hide: function() {
		this.popup.hide();
	}
});

He goes on to show that you can also extend this class by changing the show and hide functions to add some animation.

I also really like the benefits he stated (quoting him):

• My code is now far more legible. I have small methods that just do one thing and I know what it’s doing and why. My classes are named things that describe what they do, and the classes themselves are small things that just do one thing. If I need a class that does two things, I write two classes and a small controller class that calls them.
• My code is reusable – if the pattern ever comes up again, I don’t have to write it again. I’ve amazed myself in how often this has happened. Stuff I never, ever thought I’d reuse ends up coming back to me in a week and there I am using it again.
• The points where my application – the web page I’m working on at the moment – touches my generic code are very small. I don’t write much code about the pages themselves – all I do is instantiate classes for a given page element. This small footprint means that there’s less code that’s only good for that page.
• When it’s time to refactor – perhaps there’s a new version of the framework I’m using, or a new browser bug is found, or a new browser hits the market (oh, hi chrome), or I find a bug in my own code (which is the most frequent of all these reasons), I have to go fix it. If I’m writing all my code for each page I have to go refactor it everywhere. If, on the other hand, my pages just instantiate my classes, I only have to refactor my classes. Since I control the interface to my classes, I can completely rewrite the class without having to touch the code that instantiates them.
• Finally, I end up changing the way I think about the user experience I develop. I’m much more likely to develop an experience and reuse it than create a new one from scratch. This creates an experience consistency that, to me, means a better user experience.