Preface

In the recent days some of my study focus is the SOLID principles, Clean Architecture and some related topics like Design Patterns, and I need to confess that I was using the OOP techiniques in the wrong way since college, I realised that what I was writing was just procedural code separated in different files with classes and methods, there wasn’t a single advantage by using OOP like that, so I decided to change.

Design Principles

Every paradigm has its own principles, in the OOP world those principles are the SOLID (there are a few more, but those are the most famous and used). So what this means, these SOLID keywords? They stand for:

  • Single Responsibility;
  • Open-Closed;
  • Liskov Substitution;
  • Interface Segregation;
  • Dependency Inversion;

Basically, if you build your application following all those principles, your codebase will be more flexible, abstracted and maintainable, the evolution of the software will be less painful and costly, giving you more time to expend implementing new things.

Open-Closed Principle

The Open-Closed Principle says that our classes must be open for expansions and closed for changes. Basically, we must be able to change the implementation behavior on execution-time, and to reach that, we don’t need to change the class codebase, we just need the help of composition.

There is a famous dictation that says that we need to prefer composition over inheritance, and this is really important. There are some issues when we decide to use inheritance, the first is that we’re breaking the OOP foundation of encapsulation because the children know everything about the parent. The second is the static inheritance, we can’t change the behavior of the children even in execution-time, we need to change the codebase itself to be able to change the behavior, breaking the Open-Closed Principle.

When we have composition, we no longer have the “is” relationship (Ex: SavingsAccount is an Account) and we passed to have the “has” relationship (Ex: AuthorizationClient has a HttpClient), so, following the example, AuthorizationClient behaves like a normal HttpClient, but he can change your default behavior, adding an authorization header for example.

#javascript #decorator-pattern #solid-principles #typescript #software-development

Applying Open-Closed Principle with Decorator Pattern in Typescript
3.00 GEEK