A Fast Review On Principles Every Developer Should Know
In this article I try to review some of software development principles I know, Like DRY, YAGNI, KISS and of course SOLID.
DRY VS WET
DRY stands for “Don’t Repeat Yourself” and WET stands for “We Enjoy Typing”.
I think we can divide programmers in one of these two categories and in my opinion it’s better to be DRY. But why? Programmers who choose DRY, try to write a code once and use it in other parts in comparison with rewriting the previous code every where they need the same logic. Primary pros of DRY is that you don’t need to repeat your code again and wherever you need the logic, you could just reuse it. Secondly if you need to change a part of your logic with DRY you just need to change in one place, but imagine if you repeated that piece of code at any other parts of your program.
DRY principle says that there should only be one of any important piece of information. The reason for this principle is that having one piece of code is much easier to maintain than multiple ones; if the information needs to be changed, there is only one place to be changed.
YAGNI:
YAGNI stands for “You aren’t gonna need it”. It is a concept often used in agile software teams. It’s a statement which claims that some capability we presume our software needs in the future, should not be built now because “you aren’t gonna need it”. Always implement things when you actually need them, not when you foresee that you will need them.
This basically means that even if something might be needed in the future, it shouldn’t be done NOW. A big project develops on base of a little project which you could say “It worked”.
KISS:
KISS stands for “Keep it simple stupid”. This principle was first used by US Navy “Keep it simple soldier”. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
When a program grows in size, the complexity of the code tends to increase and nobody likes to maintain complex code. So always try to develop As simple as you can. It’s not a good habit to solve a problem with a complex solution when there is more simple solutions.
SOLID:
As Wikipedia says SOLID is acronyms for five design principle in Object Oriented programming intended to make software design more understandable, flexible and maintainable. As we have a rule in software engineering High cohesion and low coupling, all the principles in SOLID try to Remove coupling of instances to improve the ability of maintenance and adding new features.
Single Responsibility Principle:
A class should only have a single responsibility, that is, only changes to one part of software’s specification should be able to affect the specification of the class.
So simply this principle says when you write a class your class should only have one job to do and nothing more. So when you need to have a change in your logic, just one class should be affected of that change. This principle reminds me Swiss knife. The problem is if you want to change one of the parts of the knife you need to change in the whole knife not just that certain piece, which is not desirable according to this rule.
Open Closed Principle:
Software entities should be open for extension but close for modification. So what do we understand from this principle? This principle says by every change in requirements you should not change your previous code, you just need to extend that part and then meet the new requirement.
Imagine you have a customer class. In this class there is a method that base on customer type it returns percent of discount for that customer. If you need to add a new customer type there would be a problem. You need to change that method. And every time you change you need to check that new code works or not. But what if you had a base class for customer and with every new customer type you just need to inherit from that and implement your method base on new customer type without changing previous customer classes.
Liskov Substitution Principle:
Objects in a program should be replaceable with instances of their sub types without altering the correctness of that program. This rule extends Open-closed principle by focusing on parent and child classes. This principle says that the objects of your child class should behave in the same way as the objects of your parent class.
There is a famous example for this principle. In mathematics a Square is a Rectangle which it’s width and height is equal. Based on Liskov substitution principle if you inherit a Square class form a Rectangle class, then objects of Square should be usable anywhere you expect a Rectangle object. Here is the problem, you have 2 attribute height and width in your rectangle object but in a Square object you just need one of them.
Interface Segregation Principle:
Clients should not be forced to depend upon interfaces that they do not use. This principle says that Interfaces must be developed so that classes should not be forced to implement methods that they don’t use. This principle is like the first one. Suppose that You declare an interface for animals with a flying method. But how do you want to implement this method for Fish class?
Dependency Inversion Principle:
High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details.
When you develop an Object Oriented program normally your objects depend on each other. Imagine you have a class that using all of it’s method sends an Email to somebody. If you set an attribute of your class to be an instance of Email class it would work fine, But what if you need to send an SMS? You need to change your class to create an instance of SMS class. So as you see it’s not a good design. Based on Dependency Inversion principle it’s better to create an Abstract for sending information and then your modules depend on that abstraction.
Conclusion:
Designing a project with these principles at first sight could be a hard work to do but it makes maintenance and development in long run very easy. Sometimes you could ignore these principles in your work because of lack of time or etc. But it’s a debt that must be paid some day. So it’s a good idea to know what problems your project may face if you ignore these principles.
And as the cover says it’s about 20–80 rule. Sometimes you had 20% effort and you developed 80% of your project but for developing the rest 20% of your project, you need to push 80% effort.
