Introduction to Design Pricinples
Well, we all agree that the software design is one of the important aspect of the software development. Its challenging to build the software that are functionally accurate and easy to maintain. Also sometimes the early stage decision made will help the software development easier. It can be costly later with bad design, which can later be in the worst situation, even to rewrite the whole system. Thus, a decision with good design should be made earlier in order for a software to last longer.
Lets discuss some design patterns
- DRY – Don’t Repeat Yourself
- KISS – Keep It Simple Stupid
- YAGNI – You Aren’t Gonna Need It
- MVP – Minimum Viable Product
- SOLID
DRY
The main thought behind the Don’t Repeat Yourself (DRY) principle is that duplication is a waste of time and effort. The repetition could take the form of processes and code. Handling the same requirement multiple times is a waste of effort and creates confusion within a solution. When first viewing this principle, it might not be clear how a system could end up duplicating a process or code. The cause of Duplicate Codes are
- Lack of Understanding
- Copy and Paste
KISS
Similar to DRY, Keep It Simple Stupid (KISS) has been an important principle in software development for many years. KISS stresses that simplicity should be the goal and complexity should be avoided. The key here is to avoid unnecessary complexity and thus reduce the chances of things going wrong.
YAGNI
You Aren’t Gonna Need It (YAGNI) simply states that functionality should only be added when it is required. Sometimes in software development, there is a tendency to futureproof a design in case something changes. This can create requirements that are actually not needed currently or in the future.
MVP
By taking a Minimum Viable Product (MVP) approach, the scope of a piece of work is limited to the smallest set of requirements in order to produce a functioning deliverable. MVP is often combined with Agile software development (see the Software development life cycle patterns section later in the chapter) by limiting requirements to a manageable amount that can be designed, developed, tested, and delivered. This approach lends itself well to smaller website or application development, where a feature set can be progressed all the way to production in a single development cycle.
SOLID
S: Single Responsibility Principle
A class should have only one responsibility. The goal of this principle is to simplify our classes and logically structure them. Classes with multiple responsibilities are harder to understand and modify, as they are more complex. Responsibility in this circumstance is simply a reason for the change. Another way of looking at responsibility is to define it as a single part of the functionality.
O: Open Closed Principle
The open/closed principle is best described in terms of OOP. A class should be designed with inheritance as a means of extending its functionality. Change, in other words, is planned for and considered while the class is being designed. By defining and using an interface that the class implements, the open/closed principle is applied. The class is open for modification, while its description, the interface, is closed for modification.
L: Liskov Substitution Principle
Being able to substitute objects at runtime is the basis of the Liskov substitution principle. In OOP, if a class inherits from a base class or implements an interface, then it can be referenced as an object of the base class or interface.
I: Interface Segregation Principle
Similar to the single responsibility principle, the interface segregation principle states that an interface should be limited to containing only methods that are relevant to a single responsibility. By reducing the complexity of the interface, the code becomes easier to refactor and understand. An important benefit of adhering to this principle in a system is that it aids in decoupling a system by reducing the number of dependencies.
D: Dependency Inversion Principle
The dependency inversion principle (DIP), also referred to as the dependency injection principle, states that modules should not depend on details but on abstractions instead. This principle encourages writing loosely coupled code to enhance readability and maintenance, especially in a large complex code base.
