Actionscript: The rules #1 – Refactor over reuse

Lately i’ve been trying to formalise a lot of the processes i use for coding actionscript so I started to write them down. I then was going to post them to my blog, however this quickly grew into a very large post, so i’ve decided to break them up into a series. Also this should make discussion of each of these points easier, and allow me to add more as i think of them (also it means i shouldnt be stuck for content for a while ;) ).

This isn’t a definitive list of best practices, and i’m sure people will disagree with me on some of the points but i think it helps to write this stuff down and discuss it. And with the introduction over it’s time to dive into the first rule.

“When creating classes don’t create them to be reused. Reusability should come from refactoring old classes”

This is an important but tricky skill to master, the ability to go back to some code you’ve already written and rework it. It can be a major headache the first time you want to reuse something, but if you can generalise a little more the code you’re useing every time you look at it, eventually you’ll end up with a solid code base. This goes hand in hand with not writing for reusability as raised by qlod, but rather letting reusablility come out of refactoring by itself.

Heres a simple example. Lets say we write a class for a specific task:

class myClass{
private var a:Number = 1
public function doSomethingWithNumbers():String{
//multiply by 2
a*=2.toString()
//then return the new value
return a
}
}

Later we want another class that does something similar. We could subclass our original like so:

class mySubClass extends myClass{
public function doSomethingWithNumbers():String{
//multiply by 2
a*=2
//then add 1
a+=1
//then return the new value
return a.toString()
}
}

However another approach is to move the common functionality to a super class, then have both classes extend this. First We create the super class:

class mySuperClass{
private var a:Number = 1
public function doSomethingWithNumbers():String{
return doSomethingSpecificWithNumbers().toString()
}
public function doSomethingSpecificWithNumbers():Number{
return a
}
}

Then we create our two sub classes:

class myFirstSubClass{
public function doSomethingSpecificWithNumbers():Number{
//multiply by 2
a*=2
//then return the new value
return a
}
}

And:

class mySecondSubClass{
public function doSomethingSpecificWithNumbers():Number{
//multiply by 2
a*=2
//then add 1
a+=1
//then return the new value
return a
}
}

So we now have two sub classes that do exactly what we wanted, and we also have a more generalised superclass, that should we want to create a third class in the future, is easy to extend for whatever we need it for.

I realise this may be an overly simplified example, but hopefully you’ll see the benefits of what i’m getting at here. Most importantly we’ve acheived reuse without having to waste time guessing what functionality we will need in the future while writing the first class. This means we’ve avoided writing any code that we don’t actually use, and anything that helps us to do less work can only be a good thing right?

  1. #1 by Keith Peters on June 3rd, 2006 - 2:13 pm

    I agree completely. A real life example, I was creating a component which is pretty much one of a kind, for a specific use, distributed to a specific audience. It’s all in one class. Now eventually, I may have a few more components that will join it. In that case, I’ll probably start building the second one, and say, “OK, this setSize method, and this move method, and this init method, all are going to do pretty much the same thing. Lets make a base class that contains those.
    I could do that now, but its unneccesary. If I were sitting down to build a family of components, obviously I’d start with a different viewpoint.

Comments are closed.


  • SetPageWidth