SOLID Software Design Solutions
When I wrote some of my first programs (not including the obligatory “Hello World”), I was more focused on whether it would compile or if I had made an error somewhere along the way. Many computer science programs in college focus on giving aspiring programmers a core understanding of tools and how to make them interact with each other to compile into a “working” application. To expand on the infinite monkey theorem first introduced by Sir Arthur Eddington, I would be willing to also assume that the same monkey typing out the works of Shakespeare could manage to type out a “working” application that would compile. But does that make him a software engineer?
In my mind, separating working, compiling code from a properly engineered application is something that is not currently taught in a normal computer science curriculum, but should be. I spent almost 8 years in the computer science industry before truly understanding why the design of an application was more important than it just compiling or working.
Why should the design of an application’s code matter? The major argument here is that if an application was written to solve a problem, and it does solve the problem, then the application is successful.[RW1] This is only true until the problem becomes more complicated, poor software design cannot change rapidly enough to help solve the rapidly changing problems.
A very interesting and mind altering (not like LSD) acronym to help young programmers start to evolve into true engineers or architects is SOLID[RW2] . First introduced by Robert C Martin[1] in the early 2000s, this acronym represents five principles of class (or ultimately software) design that when followed makes software easier to develop, maintain, and hopefully evolve.
Over the next series of blog posts I’ll explain these five principles and give examples of code that violates the principles, and how to correct it.
Single Responsibility Principle
Open / Closed Principle
Liskov Substitution Principle
Interface segregation principle
Dependency Inversion Principle
[1] http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Have you ever found yourself repeating a snippet of code over and over and over again with minimal iterations? It happens to the best of us. But when you take a few minutes to put those repeated snippets into an extension method, you can DRY Your Code and make the world a better place. “What does DRY represent?” you might ask. Don’t Repeat Yourself. Okay, this sounds a little simplistic, but give it a chance. If you can write a snippet of code once, rather than a hundred times, and then simply refer to it throughout the program as necessary, you save keystrokes and time, making your program tighter, more efficient, and easier to troubleshoot. In short, DRY Your Code, you won’t regret it.
Matthew D. Wilson's Blog 