Many developers have worked in object oriented languages and many are working in JavaScript but very few use object orientation principles together with JavaScript, Derick Bailey, an author and developer focusing on JavaScript, stated in a recent presentation at CodeMash. In object oriented programming we talk about foundations and principles as a base for our work but when moving from class based static languages to loosely typed, not class based languages, we often find it hard to apply the same principles.
Derick claims there are a lot of good principles, practices and patterns available in order to help developers writing good stable JavaScript code, one example being the SOLID principles, identified by Robert C. Martin, in the early 2000s.
Derick describes the SOLID principles as five individual patterns that play well together and walks through all five using code samples and looking at some idiosyncrasies in JavaScript that makes applying these principles a little bit different compared to when using them in languages like Java and C#.
Derick’s definition of the five principles are:
- Single Responsibility Principle. Everything should have only one reason to change. This will help developers understand the context and responsibility of what they are building and when there is a need for change.
- Open-Closed Principle. A change in behaviour should be possible without changing existing code, e.g. by using extension points and creating code that can be plugged in.
- Liskov Substitution Principle. Derived objects or types must be substitutable for their base. For Derick this is a more focused version of the Open-Closed principle.
- Interface Segregation Principle. A client should not be forced to depend on interfaces it doesn’t use. A problem is that there are no explicit interfaces in JS, but there are ways around this.
- Dependency Inversion Principle. Consists of two concepts, abstraction which states that we should depend on abstractions, not on concrete implementations and ownership that states that low level implementation should depend on high level concepts.
Derick ends with stating that if you have large monolithic chunks of code in your system, SOLID will help you break these into individual pieces. It will not decrease complexity, but will help you create abstractions and group details into larger concepts that we can reason about.