
Introducing SOLID Principles
05/06/19 • 7 min
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 47, in which we'll introduce the SOLID principles. I'll spend a little time reviewing these principles in the upcoming episodes.
What are the SOLID principles of object-oriented design?
Sponsor - devBetter Group Career Coaching for Developers
Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us.
Show Notes / Transcript
Depending on how long you've been programming, you may have heard of the SOLID principles. These are a set of 5 principles that have been around for several decades, and about 15 years ago someone - I think it was Michael Feathers - had the idea to arrange them in such a way that they formed the macronym SOLID. Prior to that, I think the first time they were all published together was in Robert C. Martin's 2003 book, Agile Software Development: Principles, Patterns, and Practices in which their sequence spelled SOLDI - so close! This same sequence was used in the 2006 book Agile Principles, Patterns, and Practices in C#.
So what are the SOLID principles? As I mentioned, SOLID is a macronym, meaning it is an acronym formed by other acronyms. In this case, these are SRP, OCP, LSP, ISP, and DIP. All those Ps at the end of each acronym stand for principle, of course. Listing each principle, we have:
- Single Responsibility
- Open/Closed
- Liskov Substitution
- Interface Segregation
- Dependency Inversion
You may already be familiar with these principles. If you're a developer who's using a strongly typed language like C# or Java, you should be extremely familiar with them. If you're not, I recommend digging into them more deeply. Applying them can make a massive difference in the quality of code you write. How do I define quality? Well, that's probably a topic I could devote an episode to, but the short version is that quality code is code that is easy to understand and easy to change to suit new requirements. It's easily and quickly tested by automated tests, which reduces the need for expensive manual testing. And it's loosely coupled to infrastructure concerns like databases or files.
How do these principles help you to write quality code? They provide guidance. You need to write code that solves a problem, first and foremost. But once you have code that does that, before you call it done and check it in, you should evaluate its design and see if it makes sense to spend a few moments cleaning anything up. Back in Episode 6 - you are listening to these in sequential, not reverse, order, right? - I talked about Kent Beck's approach of Make It Work, Make It Right, Make It Fast. SOLID principles should generally be applied during the Make It Right step. Don't apply them up front, but as I discussed in Episode 10, follow Pain Driven Development. If you try to apply every principle to every part of your codebase from the start, you'll end up with extremely abstract code that could do anything but actually does nothing. Don't do that.
Instead, build the code you need to solve the problem at hand, and then evaluate whether that code has any major code smells like I discussed in episode 30. One huge code smell is code that is hard to unit test, meaning it's hard to write an automated test that can just test your code, without any external infrastructure or dependencies like databases, files, or web servers. Code that is easy to unit test is generally easy to change, and code that has tests is also easier to refactor because when you're done you'll have some degree of confidence that you haven't broken anything.
In upcoming episodes, I'll drill into each principle a bit more. I've published two courses on SOLID at Pluralsight where you can obviously learn a lot more and see real code as opposed to just hearing me through a podcast. The first one was published in 2010 and so the tools and look were a bit dated. The more recent one is slimmed down and uses the latest version of Visual Studio and .NET Core. There are links to both courses in the show notes - the original one also covers the Don't Repeat Yourself principle. Let me wrap th...
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 47, in which we'll introduce the SOLID principles. I'll spend a little time reviewing these principles in the upcoming episodes.
What are the SOLID principles of object-oriented design?
Sponsor - devBetter Group Career Coaching for Developers
Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us.
Show Notes / Transcript
Depending on how long you've been programming, you may have heard of the SOLID principles. These are a set of 5 principles that have been around for several decades, and about 15 years ago someone - I think it was Michael Feathers - had the idea to arrange them in such a way that they formed the macronym SOLID. Prior to that, I think the first time they were all published together was in Robert C. Martin's 2003 book, Agile Software Development: Principles, Patterns, and Practices in which their sequence spelled SOLDI - so close! This same sequence was used in the 2006 book Agile Principles, Patterns, and Practices in C#.
So what are the SOLID principles? As I mentioned, SOLID is a macronym, meaning it is an acronym formed by other acronyms. In this case, these are SRP, OCP, LSP, ISP, and DIP. All those Ps at the end of each acronym stand for principle, of course. Listing each principle, we have:
- Single Responsibility
- Open/Closed
- Liskov Substitution
- Interface Segregation
- Dependency Inversion
You may already be familiar with these principles. If you're a developer who's using a strongly typed language like C# or Java, you should be extremely familiar with them. If you're not, I recommend digging into them more deeply. Applying them can make a massive difference in the quality of code you write. How do I define quality? Well, that's probably a topic I could devote an episode to, but the short version is that quality code is code that is easy to understand and easy to change to suit new requirements. It's easily and quickly tested by automated tests, which reduces the need for expensive manual testing. And it's loosely coupled to infrastructure concerns like databases or files.
How do these principles help you to write quality code? They provide guidance. You need to write code that solves a problem, first and foremost. But once you have code that does that, before you call it done and check it in, you should evaluate its design and see if it makes sense to spend a few moments cleaning anything up. Back in Episode 6 - you are listening to these in sequential, not reverse, order, right? - I talked about Kent Beck's approach of Make It Work, Make It Right, Make It Fast. SOLID principles should generally be applied during the Make It Right step. Don't apply them up front, but as I discussed in Episode 10, follow Pain Driven Development. If you try to apply every principle to every part of your codebase from the start, you'll end up with extremely abstract code that could do anything but actually does nothing. Don't do that.
Instead, build the code you need to solve the problem at hand, and then evaluate whether that code has any major code smells like I discussed in episode 30. One huge code smell is code that is hard to unit test, meaning it's hard to write an automated test that can just test your code, without any external infrastructure or dependencies like databases, files, or web servers. Code that is easy to unit test is generally easy to change, and code that has tests is also easier to refactor because when you're done you'll have some degree of confidence that you haven't broken anything.
In upcoming episodes, I'll drill into each principle a bit more. I've published two courses on SOLID at Pluralsight where you can obviously learn a lot more and see real code as opposed to just hearing me through a podcast. The first one was published in 2010 and so the tools and look were a bit dated. The more recent one is slimmed down and uses the latest version of Visual Studio and .NET Core. There are links to both courses in the show notes - the original one also covers the Don't Repeat Yourself principle. Let me wrap th...
Previous Episode

On Sleep with Guest Jamie Taylor
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 46, with guest Jamie Taylor, aka GaProgMan.
On The Importance of Sleep
Sponsor - devBetter Group Career Coaching for Developers
Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us.
Show Notes / Transcript
This week's tip comes to us from the UK, where fellow podcast host Jamie Taylor lives. He has a great tip that will help improve your health and productivity. Take it away, Jamie!
Hello everyone, I'm Jamie "GaProgMan" Taylor, I'm the host of The .NET Core Podcast, and Steve has graciously agreed to let me share a tip with you all. My plan isn't to talk to you about .NET Core or even development, per se, but I might use them as a background for what I do want to talk about: and that's finding the time to relax and getting enough sleep.
We work in a very fast paced industry, it seems like the technology space is constantly evolving. The breakneck pace of our industry can seem overwhelming to most of us, especially if you want to keep up with the latest innovations. I know that I've been guilty, in the past, of saying something like:
the moment that you stop learning, you're already a day behind
Which, other than being hyperbole, is a bit of a double edged sword. On the one hand, it's a great idea to keep to speed with what's going on; but on the other hand, you need down time.
Now I don't care how long you can sit at your laptop, coding into the wee hours of the morning, drinking coffee, Red Bull, Mountain Dew, or whatever your incredibly sugary caffeinated drink of choice is. Eventually, you are going to need some rest and relaxation.
And rest is the most important thing. Your body, whether you are aware of it or not, can go for days without food - it would be tough, but it's doable. But you cannot go for days without resting. To quote one UC Berkley article on the subject:
As little as one night without sleep is enough to turn a reasonable person into "emotional Jell-O," says Matthew Walker, director of Berkeley’s Sleep and Neuroimaging Laboratory
The brain is the most important part of the body for a developer. Without it, we can't function (if you'll pardon the pun). We need the ability to deal with complex business logic, hold several layers of the application's design in our short term memory, and to be able to parse customer requirements.
Without a healthy, well rested brain you can't do any of this. In the words of John Silva (host of National Geographic Channel's "Brain Games"):
One of the things that happens when you're sleep-deprived is that your ability to regulate emotions goes haywire. Your brain becomes disorganised in its capacity to process information and your sensitivity to information also get scrambled.
Regulating emotions is an incredibly important skill to have, and becoming disorganised is quite possibly the antithesis of the state of mind that a developer needs to be in. You need to be able to focus on the task at hand.
"But I'm an extremely well motivated go-getter, Jamie. I really don't care." Eventually you are either going to crash and burn, or you're going to need the help of a team of doctors, and possibly a hospital.
When you don't rest, you're not just affecting you're physical health, but you're also putting your mental health at risk. Without sleep, you'll be unable to put your thoughts in order, which means that you won't be able to communicate with others, which will lead to you becoming agitated, and that will lead to stress.
And stress (or more correctly, "distress") can wreak havoc on your body. We're talking headaches, increased blood pressure, chest pain, heart problems, skin conditions, depression, and anxiety to say the least.
So what can we do?
Firstly, get up and walk away from your computer. Maybe not, right now. But the next time you get a chance to do so: do it. Take a walk, preferably outside; and if you really must have a coffee, walk to the next coffee shop along - the extra time in the fresh air will really help you.
Spend time away from a computer of phone screen, as little as 15 minutes for every 45 will really help. Walk over to the water cooler and have a chat with someone while you get a cup of wat...
Next Episode

Effective Ways to Accelerate Your Career
Hi and welcome back to Weekly Dev Tips. I’m your host Steve Smith, aka Ardalis.
This is episode 48 on Effective Ways to Accelerate Your Career, with guest James Hickey.
Effective Ways to Accelerate Your Career
This week's tip is brought to you by devBetter.com.
Sponsor - devBetter Group Career Coaching for Developers
Are you a software developer looking to advance in your career more quickly? Would you find a mentor and a group of like-minded professionals valuable? If so, check out devBetter.com and read the testimonials at the bottom of the page. Sign up for a risk free membership if you're interested in growing your network and skills with us.
Show Notes / Transcript
This week's tip is brought to you by guest James Hickey. James is a software developer working remotely in eastern Canada. James helps software developers gain traction in their careers with his free email newsletter, "Navigating Your Software Development Career", which I link to in the show notes. He's also the author of an open source .NET Core library called Coravel, which provides advanced capabilities to web applications. James is going to share some tips on accelerating your career. Welcome to Weekly Dev Tips, James!
Hi! I'm James Hickey.
I'm a senior .NET developer and consultant based in eastern Canada. I'm also the author of an open source .NET Core library you might be familiar with called Coravel.
One of the big realizations I had early on in my career was that doing a good job and doing what I was told to do would actually not lead to:
Promotions, recognition, becoming really skilled at my craft, and opening up more opportunities.
Many developers find themselves comfortable with having an easy and carefree job with minimal responsibilities.
Other developers, like myself, have an inner drive, ambition, and passion to be the best that we can be.
We recognize that having options means we can support our families better, have more money and resources to help our friends when in need, have the ability to create new businesses that solve important problems in our world, and know that we can inspire others to conquer obstacles in their own lives.
Are you one of these developers?
Here are some tips for you to accelerate a bit faster in your career!
Find Gaps
Here's my first tip.
Early in my own career, there were times when I would solve a problem and developers who were more senior than I would ask, "How did you that?"
One example was when I worked on a large database migration project. My colleagues were building various scripts that could take days to run.
When I started building my own scripts, I started using regular expressions in SQL to fetch certain patterns in the data, manipulate it and then store the results. My solutions were taking mere hours to run!
I became known as the guy who could migrate these large data sets very well. The senior developers would start coming to me for advice whenever they needed help in this area.
Have you ever solved a problem and then been asked questions like these?
- "How did you do that?"
- "What did you do there?"
- "Why did you do that?"
This probably indicates that you've found a knowledge or skills gap in your team. You should jump all over that topic and become the "go to" person.
You might think that being known as the "regular expression guy" is not that useful.
But that's not what people will think.
In reality, you will be viewed as someone who can think outside the box. You will be viewed as someone who can solve tough problems.
So, when promotion time comes along, guess who will be already on the minds of the decision makers?
Connecting With Past Co-workers
Here's tip number 2.
If you've been in the field for a few years and have worked for a few different companies, then this next tip is for you.
One thing I started doing is contacting past co-workers and managers on LinkedIn.
First, I will ask them how they are doing. Next, I'll let them know - in a couple sentences - what I've been up to recently. And finally, I'll let them know that I am available to chat with them and help them with anything they need.
This is a short and concise way to connect with them on a personal level and let them know that you are just there to help them in any way.
Don't expect to be told immediately that your past co-workers have something they need help with. (Although that has happened to me, and I've landed some big opportunities this way.)
The main point is to merely put it in the minds of these people that you are available. When they move on to another company and are looking to hire software developers, guess who's going to come to mind first?
If you have a h...
If you like this episode you’ll love
Episode Comments
Generate a badge
Get a badge for your website that links back to this episode
<a href="https://goodpods.com/podcasts/weekly-dev-tips-155124/introducing-solid-principles-8360104"> <img src="https://storage.googleapis.com/goodpods-images-bucket/badges/generic-badge-1.svg" alt="listen to introducing solid principles on goodpods" style="width: 225px" /> </a>
Copy