31 May 2019

Packages

Back-end UI

I’m sure most programmers know about SOLID design principles, and abide by these to the best of their knowledge when creating your newest piece of art. One principle that I personally enjoy reading about, is the Single Responsibility Principle. This principle, in short, is only having a single reason for your class to change. The class should only have one job and through Inversion of Control (amongst others) can delegate jobs to other classes.

So, what can be done next for maintainability? Well, any classes, code files, etc. Should be packaged together. This can be folders in your project or Class Libraries for .NET. The importance is, any files that change together stay together – Common-Closure principle.

For example:

If you have a navigation for a website all code files for this navigation to work, such as HTML, JS, CSS and business logic (C#, PHP, Java) will be placed within a package.

The benefits of this is a package will contain all code needed for that component to work. If you want to change any of the code or styles of this component all items will be in a single place. This makes the package very reusable. Packages can be managed and versioned, tools like NuGet help with storing packages and allowing developers to add these via a feed to their projects.

Packages may rely on other Packages (dependencies) a common problem when creating websites or software can be the dependencies rely on another dependency that are more likely to change. If the Packages was to change often this can cause other packages to change as well. There are patterns that have been created to stop this happening such as Helix for example. Typically, a package should only depend on another package that is less likely to change than itself, this is known as the Stable Dependencies Principle.

Get in touch