How Extendable should code be?

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.


Almost every language has features which allow extension. Ruby is a language that has extension as it’s core feature, the idea that “Everything is an object”. This essentially means the every class in ruby extends another class, and this class extends another class, until the object class, which extends itself. This essentially makes Ruby a turtle language- every object is extended by object. Because of how inherent extension is in Rubies design, when developing for Ruby you should try and make your code as extensible as possible, because it is much easier than in other languages. This also suggests that for code that needs to be extensible, you should use Ruby.


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

editors

editor1

controller.php

view.php

editor2

controller.php

view.php

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. 


Blank code file

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. 

blog comments powered by Disqus