One of the biggest topics that comes up in the field of programming today is extendability. The prevailing feeling is that code should be maintainable, easy to read, and easy to add. This idea has become so popular because it is effective in reducing the hours developers have to work on a problem. While most try to write extensible code, developers often disagree about the degree of extensibility that a program needs to have.
Unfortunately, for a recent project I needed to make the code extensible, but the project required integration with LiveDocx, and to do that I needed to use php. To further compound the problem, I was my own boss, so there was no one to tell me what to do. So I started up the project with php, and started working.
I first wrote the code that would integrate the dropbox API client I was using with the base concrete5 system. Then I wrote the code I needed to list all the files, and I started working on the code to decide what type of editor to use. I had realized that this would be something that should be very extensible so that I could add different types of editors. So I implemented the editor structure with the file layout of
editor.php contains two objects; the EditorController class and the Editor interface. Each editor controller file implements the interface and extends the class. While this is a fairly basic example of extension, it was easy partly because I had planned ahead about what layout I would want and had wrote every line of code with a purpose in mind.
I finished up the editor “layer”, and then squashed a couple bugs. After this, I was trying to think of possible feature enhancements in the future, and several came to mind. One was to allow editing of files from multiple cloud apps, like CloudApp. Another possibility was loading the file from a desktop app. However, neither of these features are integrated into the final version of the app.
The reason for their exclusion is because I hadn’t built an extension system at that level. After I realized that I hadn’t built an extension system for them I realized that I should have planned for future expansion earlier on in the project, that I should have thought about all the ways that Cirrus could expand, not just the obvious expansion points.
This got me thinking though, and I wondered if it was possible to make containers for all the possible expansion methods? Dependency Injection containers come close, but ultimately they rely on sorting the options independently. Any code that I could possibly write could be extended in one way or another, so I would never solve the problem completely, there would always be more code that could be extended.
So what’s the most perfect, maintainable, extensible code? A blank file. You can do anything with it, write it in any language, and run it on any machine. No architecture decisions have been made for you, but you have to do a lot of work to get where you want to go.