Hello everyone, surely you are more or less likely to have heard phrases such as SOLID principles, SOLID Principles, many articles related to the topic above. However, SOLID Principles is just one of many other principles in software development, in this article we will learn more about some of them.
In software design and programming, Design Principles is a set of rules and norms to help you build and design the best system for easy development and maintenance. and works well. There are differences between Design Principles and Design Patterns, such as Design Principles are design principles and principles, and Design Patterns are design templates. It can be simplified as follows that Design Principles will give you suggestions to solve a problem, and Design Patterns will give you details on how to solve that problem.
Some Design Principles
1 DRY
DRY Principle is defined as follows
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
I roughly translate: Each knowledge part must have a unique, clear, authoritative representative in a system. But do you wonder what is “Each piece of knowledge” or “Every piece of knowledge” here ?.
I have an example as follows: you need to send items to someone else, you will need to handle the job every time you send items many times, in many places, for example if you send to 10 people, you will have to handle logic for sending jobs is 10 times. Then when there is a request to change the handling when sending the item, it takes time to change the shipping logic 10 times. One solution is to put the delivery handling job in one place “Every piece of knowledge must have a single, unambiguous”, and then reuse its representation anywhere, just like you would. Define a class specifically for logic processing and call instances of that class where it is needed.
Summary:
- Repeat logic, knowledge will definitely violate DRY.
- Repeating the code is not meant to be a DRY violation.
2 KISS
KISS stands for Keep It Simple, Stupid . I roughly translate it: Keep it simple, idiot KISS thinks to make everything (source code) simple, this principle promotes simplicity in problem solving. I can give an example as follows: in a function you have to solve many subproblems, instead of writing all the ways to solve each subproblem in a function, you should divide it into small functions to solve. Solve each of those subproblems, don’t let a function solve hundreds of lines of code. Breaking down into small functions to solve each sub-problem helps you and others to easily see what works to do for that function to work.
The benefits of using KISS are: it helps you improve your ability to solve more problems with better speed, can help build large systems but is not too confusing, and can help you solve your problems. Psychological inhibition when building complex functions. It also makes it easier for others to read the flow of your source code.
3 YAGNI
YAGNI stands for You aren’t gonna need it meaning you should never code the functions you need later. It is very time consuming because you will have to think about system changes to perform that function, change the database, not only that, your source code becomes unnecessarily complicated. You can see this as an application of the KISS principle above.
If you violate the YAGNI principles, the following problems are likely to occur:
- Cost of building: you perform functions without ultimately needing it. This will cause you to spend more effort in designing, coding, testing, ..
- Cost of repair: when the function you are planning to develop is necessary, but installs inappropriately, it may be due to a conflict with existing functionality, which will take you a lot of effort to develop. Re-plan, re-install, re-test old functions, these are really unnecessary.
- Cost of delay: you will spend time thinking about the functions you plan to develop even though it is not needed at the moment, which leads to a delay for the functionality being developed.
- Cost of carry: when you add unnecessary functions, you will spend effort maintaining and editing both your new and old code.
4 Boy Scout Rule
The Boy Scout Rule is a concept based on the Boy Scouts of America rule. The rule says “Leave the campground cleaner than you found it,” which means keep your campsite cleaner by the time you arrive. If you apply this rule to your code it would be: “Always make the code cleaner when you open it up”. We should try to improve a module line no matter who the author is, for example the unused code we can remove. If you follow this rule, you will see the system get better and better, you will care about other people’s code, just as they care about your code.
Taking care of your code is one thing, taking care of the team’s code is another. Team help each other and clean up together. We follow BSR because it’s good for everyone.
summary
Above are some of the Design Principles that I find can be applied a lot and easily, hope my learnings and sharing will help you. Hello and see you in the following article xD.