I’ve written at length regarding the benefits of having your team work from a common code framework, and I can’t push that point enough.  Productivity goes up, as does the overall satisfaction and morale of the team members (after the initial pain subsides).

So where is a good place to start in planning out a framework of code?  You can always start with the data.  The only reason for an application (yes, including websites) to exist is to control some piece of data.  After all, computers are just big piles of switches controlling the flow of electrons.  The state of those switches is what we refer to as data.

To look after your data, you will want to start off with some structures in your framework that allow you to search through the data, retreive items, and sort the items in various ways.  Most people are familliar with arrays for this kind of thing, but an array is just the beginning of data structures.  Beyond the simple array are many more: maps, queues, linked lists, hash tables, etc.  In general, such structures allow the handling of data to happen seamlessly and faster than your standard array, which relies alot on looping to go through its data.  Many data structures, on the other hand, use a node-based system, making for much faster iteration.

Speaking of which, once you have your data structures in place, it only follows that you will need a quick way of going through the data.  You could reinvent the wheel, but there is a design pattern already laid out for iteration of data, predictably called the “Iterator” pattern.  This allows you to separate the searching of data from the storage of the data, so that you can have more than one way of going through the same data, and can choose one as you see fit.

Right now I’m evaluating a little framework that doesn’t have a data structures package in place, and it is hurting badly because of it.  There are lots of little examples of quick one-off data structures that have no iterators.  It leads to improper inheritance.  For instance, in one case a group of graphics-based drawing classes are inheriting from what is essentially a Map data structure just so they all can store their parameters somewhere.  Clearly, this calls out for a true Map and composition over inheritance.

With decent data structures in place, one can start to look at how bits of the framework will communicate one with another.  It is common practise to use an Observer pattern for this, in fact many languages rely heavily upon Observer for their own internal classes.  AS3 is  a perfect example.  In AS2 you may choose to roll your own.  This is not too difficult, as an Observer pattern (of broadcasters and those who subscribe, or listen to the broadcasts) is essentially a clever use of a data structure.  Listeners to broadcasters are added to a collection, and iterated through each time a ‘broadcast’ is fired.

As I go about refactoring this little framework, I hope to post more notes as I go.  It is interesting to watch a code framework grow up.