Borak - software developer illustrational
Blog
5.2. 2019 / 00:00

javascript

typescript

sw patterns

SOLID principles in Typescript and software erosion – Single responsibility part

In the ancient times of frontend development under the ECMA 3, it was really difficult to follow most of the software design principles. Most of the constructs the good design rules advised for other programming languages were not simply present in the javascript engines.
SOLID is a set of software design principles that improve the legibility of code and prevents Software erosion in the lifetime of the application.

Things slightly changed with release of ECMA 5 followed by ECMA 6 specification. Although it enabled a great leap in the methodologies of the frontend development, the right ingredients  for design patterns like SOLID were provided with Typescript.

To make better image of what the SOLID stands for and what are the results of following this set of rules, let’s look at what the software erosion is.

The times a frontend developer’s main focus was to make it work somehow are long gone.

Software erosion

Software architecture design in its beginnings is probably mostly well-structured set of patterns. As the software’s lifecycle move on in the time, it can start to rot. Mostly because of the mix of bad architectural decisions and not properly chosen changes to it’s structure.

Sometimes, actually very often, the software get to the state, where any change is more and more difficult. The situation may get so bad, that every small change in the functionality of the application is so time consuming and error prone, that management is afraid to order any changes at all.

The signs of the corrosion of the software are mostly the following:
  • Rigidity
  • Viscosity
  • Immobility
  • Fragility

Rigidity

The rigidity of the software is the state, where every change in the application is very error-prone. The changes take too much time and bugs, due to changes, arise in an unacceptable amount. Change in one place, mostly thanks to tight-coupling requires vast amount of changes at other parts of the application.

Viscosity

The sign of viscosity is that changes in the software are so time consuming, that to preserve the design in proper state is so difficult, maintainers choose hack, that further shift the original architecture out of it’s proper shape.

Immobility

This attribute of the software shows up, when the tight-coupling and faulty solutions are so common in it’s shape, that it is also impossible to move or reuse modules, packages and other entities in other parts of the program. The rewriting of the entity is less difficult and time consuming.

So, what are the practices to avoid the software corrosion? There are many common rules and practices. One of which is SOLID, which stands for:
  • Single responsibility principle
  • Open Closed principle
  • Liskov substitution principle
  • Interface segregation principle
  • Dependency inversion principle

Single responsibility principle

The motto under this term is “Every class in the application should have only one reason to change”. When we have class, that doesn’t comply to this definition, we should split into more simpler classes.

This design pattern was firstly promoted by Robert C. Martin.

It says that a single entity in the programs code should couple only elements that has one common reason to change. The reason to change is meant to be defined by the actors. Actor is an entity dealing with some part of the program and, at the same time, has interest for the part to fit his needs.

Let’s look at some code of class violation this principle.

Class Car {
Private insurance: IInsurance
            setupInsurance(insurance: IInsuranceData){
            this.insuranceData = insurance
}
Private accelerate (gasPedal: IGasPedal) {
            gasPedal.push()
}
}

We have only two methods, but It’s enough to show the SRP violation. The insurance method is probably something only insurance company is interested in. On the other hand the ‘accelerate’ method is something every driver would need to use.

So, let’s do some refactoring

Class Car {
Private accelerate (gasPedal: IGasPedal) {
            gasPedal.push()
}
}

Class InsuraceData {
Private insurance: IInsurance
            setupInsurance(insurance: IInsuranceData){
            this.insuranceData = insurance
}
}

Now we have two classes. Each for one actor in the application. It also means, that if an insurance company will need some more functionality for handling the info about the car in our application, we have a class with single responsibility principle and we can either change It of extend it based on the actors needs. Without the need to do changes in the ‘Car’ class which has different actor in our case.

Conclusion

Single responsibility principle is one part of the SOLID principles architecture set. It postulates, the entity should be aggregated only from elements with common responsibility. The responsibility is mostly defined by the interest of the actor – person which will be interacting with the part of the program in question.

More by Borak

To maximalize your user experience during visit to my page, I use cookies.More info
I understand

#BORAKlive

This page is subjected to the Creative Common Licence. Always cite the Author - Do not use the page's content on commercial basis. Comply with the licence 3.0 Czech Republic.
go to top