According to several EU directives, light bulbs, white good, cars and even homes must have energy labels. These labels indicate the energy efficiency in a range from A to G, where A is the most efficient and G is the least efficient. Yesterday I was discussing my current software project with a colleague, and we concluded that they way we’ve divided our project into components is a very flexible one. And because it is so flexible, our software has become very durable, because you can replace one component with a new one, without affecting all the others in any way, as long as the functionality of the software is not changed. And because durability is a hot environmental topic today, we thought that energy-label-like quality ratings for software would not be such a bad idea.
I believe that today there is no such thing as a standardized labeling system for software indicating the quality of the software.Wouldn’t it be a nice thing for customers to see that their software suppliers deliver A quality (durable) software instead of G quality (unmaintainable spaghetti code)? And I believe that one of the key factors in creating durable software is managing your dependencies well. As soon as one component becomes entangled with another one, you’ve already lost some of your flexibility.
I’ve read the book Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin quite some time ago. He explains really well how to handle package or component dependencies, but it wasn’t until my current project that it really got through to me.
The following are my own set of guidelines for deciding how to separate my project into components. It works really well for me:
1. Create one or more domain components
These components should have NO dependencies on frameworks, implementations, XML, or what so ever. These components will most likely contain interfaces, and domain logic. These components should capture the (abstraction of) the functionality of your application. And most important: no dependencies to implementations or frameworks!!
2. Create well isolated implementation components
Implement your domain logic in separate components. And don’t put ALL of the implementation in 1 component. For example, if your application has a view and some sort of data storage that should be used by your domain logic, create a separate view implementation component and a separate data source component. If you would have put them in the same component, your view depends on the data source implementation which is not a good thing.
3. Don’t fall back on shortcuts, it will never help you in the end
Once you use shortcuts or the fastest solution instead of the best solution, software durability and flexibility drops, especially if you create dependencies between components. If you think “oh well, lets just implement the quickest way to pass this extra information” while this information is not related to this component, you mix up responsibilities, create unwanted dependencies, and eventually you’ll end up with a highly entangled product. So be aware of shortcuts!
4. Think: “can I replace this component without affecting something unrelated”
This is a thought I keep in my mind constantly. For our front-end application we used to have only 1 component. Now we’ve separated this application into components with their own responsibilities and their own dependencies. This increased the durability of out application immensely. As long as the functionality of our application does not change, one can decide to use a different front-end framework, while the rest of the components can remain.
5. Think composition
You’re almost always better of composing your application out of small components than creating one bulky component that does all. Being able to compose your application is the path to flexibility.
Creating a highly durable product is fun and very satisfying. Summarized I would recommend: no shortcuts, separate responsibilities, domain logic with no dependencies, application composition.
