The Reason for SOLID
In general, when you think of rules and principles created to make anything better, you think it happens organically over many years by many people. Well, would you believe SOLID principles didn’t exist until the year 2000? They are a subset of many principles developed by an American software engineer and instructor, Robert C. Martin, known as “Uncle Bob.”
Many times, developers will write software by diving in head-first and not give much thought to how the overall architecture will look and react to change over time. The code then becomes brittle and inflexible, which we call “code smells.”
Making any small change could have a domino effect by creating bugs in other areas of the software. Adding a new feature could result in rewriting large chunks of code, which also has the same domino effect for bugs.
To avoid these pitfalls, you should always follow the SOLID principles. These five principles for object-oriented design (OOD), when used together, make it easier for a programmer to develop software that is easier to maintain and to extend.
SOLID stands for:
Single responsibility
Open/closed
Liskov substitution
Interface segregation
Dependency inversion
In Part 2 of this course, we will focus on each principle by learning when to apply it and by working with examples.
We'll also strengthen your design powers by learning the principles to avoid: STUPID.
The STUPID Principles
Earlier I was talking about what happens when developers don’t follow the SOLID principles and thus write code that “smells.” But, don’t let that get you down, because every developer, including myself, has written STUPID code.
So, what are these STUPID principles?
STUPID stands for:
Singleton
Tight coupling
Untestability
Premature optimization
Indescriptive naming
Duplication
At the end of Part 2, I will explain each principle in greater detail and how to avoid them in your code.
The idea of learning these STUPID principles is to make you more aware when they are happening as you develop software and, thus, better prepared to avoid them.
By understanding both the SOLID and STUPID principles, you will be well on your way to writing well-designed software.
Let’s Recap!
Cleaner designs are easier to understand, maintain, modify, and test.
Following the SOLID principles leads to cleaner design:
Single responsibility
Open/closed principle
Liskov substitutability
Interface segregation
Dependency inversion
Following the STUPID principles leads to problems:
Singleton
Tight coupling
Untestability
Premature optimization
Indescriptive naming
Duplication
Now that we’ve covered the basics of quality code, meet me in the next chapter, and we'll start putting this together with MVC!
