SOLID is an acronym that stands for the five basic principles of object-oriented programming and design. Following SOLID allows for programmers to create systems that can be easily managed and extended over time.
Single Responsibility Principle – Every module or class should only be responsible for one part of functionality. There should only be one reason for a class or module to be changed. The wiki talks about an example of how you should not need to change a class or module for more than one reason; if content and styling need to be changed, that should require changing 2 different modules / classes, and not just one. One module or class should not have functionality that affects more than one thing (ex. content and styling). Each module / class should be encapsulated to minimize breaking code when you change something.
Open/Closed Principle – “Open for extension, closed for modification.” Open means it is possible to add fields to the data structures or new elements. Closed means it can be used by other modules. Inheritance is useful, because you can add subclasses that will inherit from the parent and add something different, without changing the parent class.
Liskov Substitution Principle – “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.)” Type is different from class. Classes define how objects are implemented while type refers to its interface (the set of requests to which it can respond). <— Taken from Stack Overflow!
Interface Segregation Principle – “many client-specific interfaces are better than one
general-purpose interface.” Also called role interfaces, these smaller interfaces keep a system decoupled and make it easier to refactor, change, and redeploy.
Dependency Inversion Principle – Called inversion because it may be inverted to the way some people think about object oriented design. According to wiki:
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
Rather than having low level modules dependent on high level ones, they should all be independent. I think the general point of DIP is the decrease dependencies in your code. I can see how dependencies can be bad for code since one change in a piece of code could affect another piece of code, which may not be what you wanted to do.
Hmmm… I can’t say I completely understand everything in SOLID yet, but this is definitely a start. I’ll try to update this post when I have a better grasp of everything!
- Importance of Good Software Design
- Why Software Design Matters
- OO Design Principles
- 3 Software Principles You Must Understand
- The Principles of Good Programming
- 10 Object Oriented Design Heuristics for Rubyists
- OO Design Heuristics
- Code Smells: Your Refactoring Cheat Codes