While this book does not cover object-oriented programming, some object-oriented design principles are universal and could be applied to any programming language and paradigm. Here, we will take a look at some of the most well-known design principles. In particular, we will cover the following:

• SOLID: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion
• DRY: Don't Repeat Yourself
• KISS: Keep It Simple, Stupid!
• POLA: Principle of Least Astonishment
• YAGNI: You Aren't Gonna Need It
• POLP: Principle of Least Privilege

Let's start with SOLID.

• S: Single Responsibility Principle
• O: Open/Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle

Let's understand each concept in detail.

The Single Responsibility Principle states that every module, class, and function should be responsible for a single functional objective. There should be only one reason to make any changes.

The benefits of this principle are listed here: 

• The programmer can focus on a single context during development.
• The size of each component is smaller.
• The code is easier to understand.
• The code can be tested more easily.

The Open/Closed Principle states that every module should be open for extension but closed for modification. It is necessary to distinguish between enhancement and extension—enhancement refers to a core improvement of the existing module, while an extension is considered an add-on that provides additional functionality.

The following are the benefits of this principle: 

• Existing components can be easily reused to derive new functionalities.
• Components are loosely coupled so it is easier to replace them without affecting the existing functionality.

The Liskov Substitution Principle states that a program that accepts type T can also accept type S (which is a subtype of T), without any change in behavior or intended outcome.

The following are the benefits of this principle: 

• A function can be reused for any subtype passed in the arguments.

The Interface Segregation Principle states that a client should not be forced to implement interfaces that it does not need to use.

The following are the benefits of this principle: 

• Software components are more modular and reusable.
• New implementations can be created more easily.

The Dependency Inversion Principle states that high-level classes should not depend on low-level classes; instead, high-level classes should depend on an abstraction that low-level classes implement.

The following are the benefits of this principle: 

• Components are more decoupled.
• The system becomes more flexible and can adapt to changes more easily. Low-level components can be replaced without affecting high-level components.

We'll now cover the DRY principle:

• D: Don't
• R: Repeat
• Y: Yourself

This acronym is a good way of reminding programmers that duplicate code is bad. It is obvious that duplicate code can be difficult to maintain—whenever logic is changed, multiple places in the code are affected.

What do we do when duplicate code is found? Eliminate it and create a common function that is reusable from multiple source files. 

In addition, sometimes code is not 100% duplicated but instead is 90% similar. That is not an uncommon scenario. In that case, consider redesigning the relevant components, possibly refactoring code to a common interface.

Let's talk about the KISS principle:

• K: Keep
• I: It
• S: Simple
• S: Stupid!

Often, when we design software, we like to think ahead and try to deal with all kinds of future scenarios. The trouble with building such future-proof software is that it takes exponentially more effort to design and code properly. Practically speaking, it's a conundrum—there is no 100% future-proof solution because technology changes, business changes, and people change. Also, over-engineering could lead to excessive abstraction and indirection, making a system more difficult to test and maintain.

In addition, when using Agile software development methods, we value faster and high-quality delivery over perfection or excess engineering. Keeping the design and code simple is a virtue that every programmer should keep in mind.

Let's look at the POLA principle:

• P: Principle
• O: Of
• L: Least
• A: Astonishment

POLA states that a software component should be easy to understand and its behavior should never be a surprise (or, more accurately, astonishing) to the client. How do we do that?

The following are some things to keep in mind:

• Make sure that the names of the module, function, or function arguments are clear and unambiguous.
• Ensure that modules are right-sized and well maintained.
• Ensure that interfaces are small and easy to understand.
• Ensure that functions have few positional arguments. 

Let's move on to the YAGNI principle:

• Y: You
• A: Aren't
• G: Gonna
• N: Need
• I: It

YAGNI says you should only develop software that is needed today. This principle came from Extreme Programming (XP). See what Ron Jeffries, co-founder of XP, wrote in his blog:

Software engineers are sometimes tempted to develop functionality that they feel the customer will need in the future. It's been proven time and time again that this is not the most effective way to develop software. Consider the following scenarios:

• The functionality is never needed by the customer and so the code is never used.
• The business environment changes and the system has to be redesigned or replaced.
• The technology changes and the system has to be upgraded to use a new library, a new framework, or a new language. 

The cheapest software is the one that you didn't write. You aren't gonna need it!

Now, for POLP:

• P: Principle
• O: Of
• L: Least 
• P: Privilege

POLP states that a client must be given access only to the information or functions that they need. POLP is one of the most important pillars for building secure applications, and it is widely adopted by cloud infrastructure vendors such as Amazon, Microsoft, and Google.

There are quite a few benefits when POLP is applied:

• Sensitive data is protected and not exposed to non-privileged users.
• The system can be tested more easily since the number of use cases is limited.
• The system becomes less prone to misuse because only limited access is given and the interface is simpler.

The software design principles that we have learned about so far are great tools. Although SOLID, DRY, KISS, POLA, YAGNI, and POLP seem to be just a bunch of acronyms, they are useful in designing better software. While SOLID principles came from the object-oriented programming paradigm, SOLID's concepts can still be applied to other languages and environments. As we work through the rest of the chapters in this book, I would encourage you to keep them in mind.

In the next section, we will go over several software quality objectives when designing software.