What is SOLID?

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!

Some links!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s