code | 3-11-2010
If you are the only person who will ever work with the code you are writing, you will at some point have to modify it. It's a fact. Code that never gets modified is a sign of a dead website. In order to modify your code, you need to write it to be easily modified without breaking other things and it needs to be easy to find what you are looking for in order to change it. If other people will be looking at your code, whether in a development environment or if you ever leave your current job and someone else has to pick up where you left off, it is crucial that your code be pristine. So where do you start? Glad you asked.
Pick a library
Use a connection object
Think of the connection object as the central hub or location where your application gets, stores and updates it's data. The key responsibilities of the connection object include initializing the modules and passing information between modules. This creates what we call "Loose Coupling" between the modules, which allows the modules to be dumb to each others existence. When a module object is updated it passes the connection object the new data and the connection object essentially shouts out to the other modules "Hey! Over here! I've got some new updates!" The other modules may ignore the announcement or they may act on the new information, but the connection object doesn't care either way, it just takes in information and sends it out.
Think in modules
One thing to keep in mind whether you use an MVC framework or you just write modular code individually is that modules should never interact directly with each other. For all purposes, a module should be dumb to another modules existence. When a module needs to apply something other modules, it should be passed to the connection object that informs all of the modules that a change has occurred. If any of the modules need the change, they will grab it from the connection object, not from the effected module itself. This keeps the actions separate and keeps modules from being broken due to changes in other modules. This greatly reduces the chance that your entire application will ever be effected by changing a single element of it.
Build a library connection object
A fourth measure of separation that I have read about but have to admit I've never used is to write an object that acts between the library and the modules create loose coupling to the library. This object only extends methods that are used by the modules from the library. The idea behind the library connection object is that if the library is ever replaced, (for example, if you need to switch from Moo Tools to Prototype because it offers functionality that isn't available in Prototype), you can easily transition to the new library without having to re-write all of your modules.
If you're anything like me, you probably need something visual to show the work-flow I'm proposing. Here's a simplified example of what this might look like. The arrows show what is being send in and what is being received by each object and module.