SOLID and Other Principles

The world of software is riddled with principles and acronyms. There are many firm and entrenched ideas about how we should go about writing code. The sheer quantity of all of them can be overwhelming, making it especially hard to know which path to take when designing an abstraction. JavaScript's ability to accommodate many different paradigms is one of its strengths as a programming language, but it can also make our job harder. It's up to JavaScript programmers to implement their own paradigms.

This chapter, in the hope of making things less complicated, will take various well-known principles and break them down so we can see their underlying intent. We will explore how these principles relate to the tenets of clean code that we have already discussed, enabling us to make our own informed decisions as to what approaches to use in pursuit...

The Law of Demeter

Before we delve into the SOLID arena, it's useful to explore a less well-known principle, known as LoD, or the principle of least knowledge. This so-called law has three core ideas:

• A unit should have only limited knowledge about other units
• A unit should only talk to its immediate friends
• A unit should not talk to strangers

You may rightfully wonder what it means for a unit to talk to a stranger. A unit, in this context, is a specific coded abstraction: possibly a function, a module, or a class. And talking here means interfacing with, such as calling the code of another module or having that other module call your code.

This is a very useful and simple law to learn and then apply to all our programming, whether we're writing an individual line of code or designing an entire architecture. It is, however, often forgotten or ignored.

Let's take...

SOLID

SOLID is a commonly packaged set of principles that are useful when constructing both individual modules or larger architectures. Specifically, it is an acronym that stands for five specific object-oriented programming (OOP) design principles:

• Single responsibility principle(SRP)
• Open-closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle

It is not vital to remember these names or even the acronym itself, but the ideas behind each of these principles are useful. In this section, we're going to explore each principle alongside JavaScript examples. It's important to note that, while SOLID relates mostly to OOP, there are deeper truths underlying it that are useful regardless of your programming paradigm.

Single...

The abstraction principle

In the first chapter, we introduced the concept of a tower of abstractions, and the idea that every abstraction is a simplified lever to hidden complexity. The principle of abstraction within programming states the following:

Implementation should be separate from interface.

An implementation is the complex underside of an abstraction: the part that it's hiding. The interface is the simplified topside. That is why we say that abstraction is a simplified lever to hidden complexity. The craft of creating abstractions that separate implementation from interface to just the right degree is not as simple as it may seem. As such, the programming world provides two warnings for us:

• Don't repeat yourself (DRY): A warning that tells us to avoid writing code that duplicates other code we have written. If you find yourself having to repeat yourself, then...

Functional programming principles

JavaScript allows us to program in a variety of different ways. Many of the examples we've shared so far in this book have been more inclined towards OOP, which primarily uses objects to express problem domains. Functional programming is different in that it uses mostly pure functions and immutable data to express problem domains.

All programming paradigms are broadly interested in the same thing: making it easier to express problem domains, to communicate our intent as programmers, and to accommodate the creation of useful and usable abstractions. The best principles we adopt from one paradigm may still apply to another, so adopt an open-minded approach!

It's easiest to observe and discuss the difference between OOP and functional programming by exploring an example. Let's imagine that we wish to build a mechanism so that we can...

Summary

In this chapter, we covered a vast amount of theory and practical skills. We covered the LoD (or principle of least information), all SOLID principles, the principle of abstraction, and a couple of key principles from the paradigm of functional programming. Even if you don't remember all of the names, you will hopefully remember the underlying knowledge and key lessons that each principle encapsulates.

Programming is as much an art as it is a science. It involves balancing all of these principles in the pursuit of crafting truly balanced abstractions. None of these principles should be considered hard-and-fast rules. They are merely guidelines that will help us on our journey.

In the next chapter, we continue this journey by exploring one of the most challenging aspects of programming, both in JavaScript and outside it: the problem of naming things.

...