Before Starting SOLID

SOLID is a set of design principles, and these principles help a programmer write better code. Table 3 shows what the acronym SOLID stands for.

Table 3: SOLID at a Glance

Whenever I address SOLID, some people find it confusing, but that’s okay—at first the principles can indeed be frustrating. Table 4 depicts the most commonly confusing aspects of the principles.

Table 4: Confusing Aspects of SOLID

Design patterns vs. design principles

In particular, people get confused between design patterns and SOLID principles. Table 5 addresses the most confusing aspects of this work.

Table 5: Design Patterns vs. Design Principles

Why coding style matters

I remember in the old days, when I was learning computer programming, I found it difficult to grasp data structure, algorithms, artificial intelligence, computer architecture, and plenty more. In those days, I didn’t take much care with my coding styles. I didn’t worry about what kind of messages I was writing to show user or what kind of messy code I was writing. I hated the tedious work of checking my code with perfect check-in messages.

As I’ve mentioned, I later came to understand how important styles are in coding. In fact, if you are not using any IDE such as Visual Studio, it’s a good idea to create your own coding styles or get a coding style guideline from your senior if you’re working on a team.

While I was doing code review, I could always identify the developer because all developers have their own unique styles of coding.

Note: For C# coders, refer to: https://msdn.microsoft.com/en-us/library/ff926074.aspx.

Object-Oriented Analysis and Design (OOAD)

OOAD is a well-known and popular technical approach to designing and analyzing an application system with the use of object orientation and the modeling of the development life cycle. Let’s look at a pictorial view of OOAD.

Figure 4: OOAD at a Glance

Note: We are not going into the details of OOAD.

Principles of Object-Oriented Design (OOD)

Object-oriented design principles are not only principles to design with, they are also roadmaps to creating well-mannered design. In the coming chapter, we will learn about SOLID in detail, but for now let’s look at an overview of all 11 principles of OOD in the following table.

Table 6: Principles of OOD

The following figure shows another way of understanding the same ideas.

Figure 5: Principles of OOD

We are not going to discuss each and every principle of OOD, but we will go over the last two parts as described by Robert C. Martin before we move forward.

  Note: Refer to: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.

Principles of package and namespace cohesion

While it’s beyond the scope of this e-book to go into great detail here, the principles of cohesion are summarized in Table 5.

Table 7: Principles of Cohesion

Principles of package and namespace coupling

Again, we won’t go into great detail here, but the principles of package and namespace coupling are summarized in the following table.

Table 8: Principles of Coupling

OOP and SOLID

OOP provides a way to write and polish our programs into better shape. These are basic points that guide us in writing a good program.

For great object-oriented designs, we need to think beyond the basics, and SOLID principles provide us a way to achieve great design. Yes, there are certain design patterns that guide us in similar ways, but SOLID exists before these patterns.

So, what is SOLID? We have seen the 11 principles of OOD—those principles are the backbone of our development, design, and analysis of applications or systems. Now, let’s briefly discuss each of the SOLID principles.

SOLID principles at a glance

SOLID principles are neither laws nor rules—they are principles intended to help us to write neat code. By following SOLID principles, our code can be easily extended and maintained.  

Single Responsibility Principle

A class should have only one responsibility. Let’s say our class is responsible for saving data. That means it should not also be responsible for retrieving data or any other tasks.

Open-Closed Principle

Once a class has been written, it should not allow anyone to make changes. No one should be able to go back and amend the class code in order to implement new functionalities.

Liskov Substitution Principle

A dependent object should be able to use any object of type parent object.

Interface Segregation Principle

A smaller interface is recommended. If an interface has one method, there will be only one place to change if we need to change the code. However, in the case of interfaces with more methods, there might be more reasons for change.

Dependency Inversion Principle

Put simply, this addresses loose coupling. With the help of DIP, we can write code that does not depend upon concrete classes.