How do you write code?
No, I’m not talking about how you name your variables/functions. Or if you put your braces on the same line as the if statement or below it. I am asking about the thought process you have when you write a class or implement a feature in your software. Do you,
- Write code to meet the current requirements exactly, maybe even hard-coding values that you are sure won’t change in the current implementation and then throwing out everything you just did to accommodate changes in the requirements?
- Strive to follow standards but still end up having to make a lot of changes to your code-base when requirements change?
- Only make a few minor changes to meet the changed requirements?
I’m sure everyone wants to be in the third group and this post is aimed at them. If you already fall into the third group, this post may not offer anything more for you but do read along and offer your comments about it.
So, eliminating code change, is that even possible? Well, you can’t really eliminate the need to make code changes, what you can do is to minimize the impact a change request can have on your code base.
How can we minimize code change? Let me introduce you to the answer to this problem, the SOLID Principles.
The SOLID principles were established in the 2000s in the field of software engineering as a way of writing code that can stand the test of time and the winds of change. They are currently well established and is a proven way of structuring your code. The name is an acronym of the 5 principles that form its base they are
| - | - |
|---|---|
| Single Responsibility | A class or function should do one thing and do it well |
| Open/Closed | A class should be open for extension but closed for modification |
| Liskov Substitution | Any subclass should be able to replace to the instances of its parent class in a program |
| Interface Segregation | Different behavior should be separated into different interfaces |
| Dependency Inversion | Higher level classes should be ignorant of the implementation details of the lower level classes and instead rely on abstractions |
I encourage you to read the Wikipedia entries I have linked above. A word of warning though, it can get complicated. At least it was for me when I started off, but don’t worry I am here to help. I’ll be running a series of posts here, on the SOLID principles. We can tackle those principles together, with code samples too. If you have anything to add, sound off in the comments. Now subscribe to this blog and check back as the posts become available.
Written with StackEdit
