SOLID

Single Responsibility Principle (SRP)

As stated in Clean Code, “There should never be more than one reason for a class
to change”. It’s tempting to jam-pack a class with a lot of functionality, like
when you can only take one suitcase on your flight. The issue with this is
that your class won’t be conceptually cohesive and it will give it many reasons
to change. Minimizing the amount of times you need to change a class is important.
It’s important because if too much functionality is in one class and you modify
a piece of it, it can be difficult to understand how that will affect other
dependent modules in your codebase.

Bad:

  1. class UserSettings {
  2.   constructor(user) {
  3.     this.user = user;
  4.   }
  6.   changeSettings(settings) {
  7.     if (this.verifyCredentials()) {
  8.       // ...
  9.     }
  10.   }
  12.   verifyCredentials() {
  13.     // ...
  14.   }
  15. }

Good:

  1. class UserAuth {
  2.   constructor(user) {
  3.     this.user = user;
  4.   }
  6.   verifyCredentials() {
  7.     // ...
  8.   }
  9. }
  12. class UserSettings {
  13.   constructor(user) {
  14.     this.user = user;
  15.     this.auth = new UserAuth(user);
  16.   }
  18.   changeSettings(settings) {
  19.     if (this.auth.verifyCredentials()) {
  20.       // ...
  21.     }
  22.   }
  23. }

Open/Closed Principle (OCP)

As stated by Bertrand Meyer, “software entities (classes, modules, functions,
etc.) should be open for extension, but closed for modification.” What does that
mean though? This principle basically states that you should allow users to
add new functionalities without changing existing code.

Bad:

  1. class AjaxAdapter extends Adapter {
  2.   constructor() {
  3.     super();
  4.     this.name = 'ajaxAdapter';
  5.   }
  6. }
  8. class NodeAdapter extends Adapter {
  9.   constructor() {
  10.     super();
  11.     this.name = 'nodeAdapter';
  12.   }
  13. }
  15. class HttpRequester {
  16.   constructor(adapter) {
  17.     this.adapter = adapter;
  18.   }
  20.   fetch(url) {
  21.     if (this.adapter.name === 'ajaxAdapter') {
  22.       return makeAjaxCall(url).then((response) => {
  23.         // transform response and return
  24.       });
  25.     } else if (this.adapter.name === 'httpNodeAdapter') {
  26.       return makeHttpCall(url).then((response) => {
  27.         // transform response and return
  28.       });
  29.     }
  30.   }
  31. }
  33. function makeAjaxCall(url) {
  34.   // request and return promise
  35. }
  37. function makeHttpCall(url) {
  38.   // request and return promise
  39. }

Good:

  1. class AjaxAdapter extends Adapter {
  2.   constructor() {
  3.     super();
  4.     this.name = 'ajaxAdapter';
  5.   }
  7.   request(url) {
  8.     // request and return promise
  9.   }
  10. }
  12. class NodeAdapter extends Adapter {
  13.   constructor() {
  14.     super();
  15.     this.name = 'nodeAdapter';
  16.   }
  18.   request(url) {
  19.     // request and return promise
  20.   }
  21. }
  23. class HttpRequester {
  24.   constructor(adapter) {
  25.     this.adapter = adapter;
  26.   }
  28.   fetch(url) {
  29.     return this.adapter.request(url).then((response) => {
  30.       // transform response and return
  31.     });
  32.   }
  33. }

Liskov Substitution Principle (LSP)

This is a scary term for a very simple concept. It’s formally defined as “If S
is a subtype of T, then objects of type T may be replaced with objects of type S
(i.e., objects of type S may substitute objects of type T) without altering any
of the desirable properties of that program (correctness, task performed,
etc.).” That’s an even scarier definition.

The best explanation for this is if you have a parent class and a child class,
then the base class and child class can be used interchangeably without getting
incorrect results. This might still be confusing, so let’s take a look at the
classic Square-Rectangle example. Mathematically, a square is a rectangle, but
if you model it using the “is-a” relationship via inheritance, you quickly
get into trouble.

Bad:

  1. class Rectangle {
  2.   constructor() {
  3.     this.width = 0;
  4.     this.height = 0;
  5.   }
  7.   setColor(color) {
  8.     // ...
  9.   }
  11.   render(area) {
  12.     // ...
  13.   }
  15.   setWidth(width) {
  16.     this.width = width;
  17.   }
  19.   setHeight(height) {
  20.     this.height = height;
  21.   }
  23.   getArea() {
  24.     return this.width * this.height;
  25.   }
  26. }
  28. class Square extends Rectangle {
  29.   setWidth(width) {
  30.     this.width = width;
  31.     this.height = width;
  32.   }
  34.   setHeight(height) {
  35.     this.width = height;
  36.     this.height = height;
  37.   }
  38. }
  40. function renderLargeRectangles(rectangles) {
  41.   rectangles.forEach((rectangle) => {
  42.     rectangle.setWidth(4);
  43.     rectangle.setHeight(5);
  44.     const area = rectangle.getArea(); // BAD: Returns 25 for Square. Should be 20.
  45.     rectangle.render(area);
  46.   });
  47. }
  49. const rectangles = [new Rectangle(), new Rectangle(), new Square()];
  50. renderLargeRectangles(rectangles);

Good:

  1. class Shape {
  2.   setColor(color) {
  3.     // ...
  4.   }
  6.   render(area) {
  7.     // ...
  8.   }
  9. }
  11. class Rectangle extends Shape {
  12.   constructor(width, height) {
  13.     super();
  14.     this.width = width;
  15.     this.height = height;
  16.   }
  18.   getArea() {
  19.     return this.width * this.height;
  20.   }
  21. }
  23. class Square extends Shape {
  24.   constructor(length) {
  25.     super();
  26.     this.length = length;
  27.   }
  29.   getArea() {
  30.     return this.length * this.length;
  31.   }
  32. }
  34. function renderLargeShapes(shapes) {
  35.   shapes.forEach((shape) => {
  36.     const area = shape.getArea();
  37.     shape.render(area);
  38.   });
  39. }
  41. const shapes = [new Rectangle(4, 5), new Rectangle(4, 5), new Square(5)];
  42. renderLargeShapes(shapes);

Interface Segregation Principle (ISP)

JavaScript doesn’t have interfaces so this principle doesn’t apply as strictly
as others. However, it’s important and relevant even with JavaScript’s lack of
type system.

ISP states that “Clients should not be forced to depend upon interfaces that
they do not use.” Interfaces are implicit contracts in JavaScript because of
duck typing.

A good example to look at that demonstrates this principle in JavaScript is for
classes that require large settings objects. Not requiring clients to setup
huge amounts of options is beneficial, because most of the time they won’t need
all of the settings. Making them optional helps prevent having a
“fat interface”.

Bad:

  1. class DOMTraverser {
  2.   constructor(settings) {
  3.     this.settings = settings;
  4.     this.setup();
  5.   }
  7.   setup() {
  8.     this.rootNode = this.settings.rootNode;
  9.     this.animationModule.setup();
  10.   }
  12.   traverse() {
  13.     // ...
  14.   }
  15. }
  17. const $ = new DOMTraverser({
  18.   rootNode: document.getElementsByTagName('body'),
  19.   animationModule() {} // Most of the time, we won't need to animate when traversing.
  20.   // ...
  21. });

Good:

  1. class DOMTraverser {
  2.   constructor(settings) {
  3.     this.settings = settings;
  4.     this.options = settings.options;
  5.     this.setup();
  6.   }
  8.   setup() {
  9.     this.rootNode = this.settings.rootNode;
  10.     this.setupOptions();
  11.   }
  13.   setupOptions() {
  14.     if (this.options.animationModule) {
  15.       // ...
  16.     }
  17.   }
  19.   traverse() {
  20.     // ...
  21.   }
  22. }
  24. const $ = new DOMTraverser({
  25.   rootNode: document.getElementsByTagName('body'),
  26.   options: {
  27.     animationModule() {}
  28.   }
  29. });

Dependency Inversion Principle (DIP)

This principle states two essential things:

  1. High-level modules should not depend on low-level modules. Both should
    depend on abstractions.
  2. Abstractions should not depend upon details. Details should depend on
    abstractions.

This can be hard to understand at first, but if you’ve worked with AngularJS,
you’ve seen an implementation of this principle in the form of Dependency
Injection (DI). While they are not identical concepts, DIP keeps high-level
modules from knowing the details of its low-level modules and setting them up.
It can accomplish this through DI. A huge benefit of this is that it reduces
the coupling between modules. Coupling is a very bad development pattern because
it makes your code hard to refactor.

As stated previously, JavaScript doesn’t have interfaces so the abstractions
that are depended upon are implicit contracts. That is to say, the methods
and properties that an object/class exposes to another object/class. In the
example below, the implicit contract is that any Request module for an
InventoryTracker will have a requestItems method.

Bad:

  1. class InventoryRequester {
  2.   constructor() {
  3.     this.REQ_METHODS = ['HTTP'];
  4.   }
  6.   requestItem(item) {
  7.     // ...
  8.   }
  9. }
  11. class InventoryTracker {
  12.   constructor(items) {
  13.     this.items = items;
  15.     // BAD: We have created a dependency on a specific request implementation.
  16.     // We should just have requestItems depend on a request method: `request`
  17.     this.requester = new InventoryRequester();
  18.   }
  20.   requestItems() {
  21.     this.items.forEach((item) => {
  22.       this.requester.requestItem(item);
  23.     });
  24.   }
  25. }
  27. const inventoryTracker = new InventoryTracker(['apples', 'bananas']);
  28. inventoryTracker.requestItems();

Good:

  1. class InventoryTracker {
  2.   constructor(items, requester) {
  3.     this.items = items;
  4.     this.requester = requester;
  5.   }
  7.   requestItems() {
  8.     this.items.forEach((item) => {
  9.       this.requester.requestItem(item);
  10.     });
  11.   }
  12. }
  14. class InventoryRequesterV1 {
  15.   constructor() {
  16.     this.REQ_METHODS = ['HTTP'];
  17.   }
  19.   requestItem(item) {
  20.     // ...
  21.   }
  22. }
  24. class InventoryRequesterV2 {
  25.   constructor() {
  26.     this.REQ_METHODS = ['WS'];
  27.   }
  29.   requestItem(item) {
  30.     // ...
  31.   }
  32. }
  34. // By constructing our dependencies externally and injecting them, we can easily
  35. // substitute our request module for a fancy new one that uses WebSockets.
  36. const inventoryTracker = new InventoryTracker(['apples', 'bananas'], new InventoryRequesterV2());
  37. inventoryTracker.requestItems();