Seeing as I’m documenting the entire road towards building my PHP Framework “Eddy”, that also includes the designing process. I don’t often make elaborate models and designs for my own home-brew software, this is definitely an exception. I want Eddy to be easily modifiable and extendable, not some hacked-together piece of poop. Now I’ve been thought that a way to achieve this is to think before you do. This post is entirely about the design process I’m currently going through to build Eddy.
Weapon of Choice
I’ll be using UML for the models. Why? Simply because I have experience with it and because I’m comfortable with it. An excellent tool for making UML models is Dia. It’s free, and it does what I need it to do. I’ve used it for projects before, both at school and at work. Again, I’m comfortable with this program and I’ve grown to love it.
Vision
At the base of the framework I want to have an object that functions as some sort of registry. The task of this object is to keep the framework together, connecting all the parts. For now, I’ll be calling this object by it’s name, “Eddy”. At this point, I am not getting into the attributes and functions of the objects quite yet. The Eddy object should be a singleton, there can only be one of them at a time. I don’t want a bunch of Eddies running around…
Eddy is supported by plugins. These plugins are tracked by Eddy and are callable through Eddy. There are abstract classes for Plugin, Model and Controller, which have to be extended to provide further functionality… This is all I have for now. This is the model I had in my head, and hopefully it will gradually become clearer as I go.