Design principles and Software Design

As we all know, design principles are the cornerstone of design patterns. When the design principles are followed, the written code becomes very flexible and can cope with changes and be easier to maintain. Of course, it is not so absolute. Next, we will briefly introduce some basic design principles, and then introduce the S.O.L. I. D principles of Robert C. Martin.

1. Brief description of Design Principles

KISS Principle (Keep It Simple Stupid)

A common problem in software development is to over-complicate a problem. The purpose of the KISS principle is to advocate keeping the code as simple as possible in design and coding to avoid unnecessary complexity. Simplicity is not equal to simplicity.

DRY principle (Don't Repeat Yourself)

The purpose of the DRY principle is to extract the public part of the system and place it in one place to avoid duplication. This principle is not only applicable to code, but can also be used in functions and business logic to ensure that there are no duplicates. This requires a good separation of system functions. Each function has a clear boundary and there is no crossover between use cases.

Tell, Don 'Task

This principle is related to encapsulation. Code should be properly encapsulated and put into the correct class. At the same time, this principle also pointed out that objects must be clearly told: What operations do we want them to perform, rather than asking the object status first, and then we decide what operations to perform.

YAGNI principle (You Ain 'tgonna Need It)

The YAGNI principle states that the system only contains the required functions and does not include the functions or features that you think may be used in the future to prevent over-design. This principle is fully embodied in TDD. In TDD, first write a test case that represents the required functions of the system, then implement the functional code of the system, and then perform a test until the test code passes.

SoC principle (Separation Of Concerns)

SoC separates a software function into a separate function. Each feature separated has unique behaviors and data, and each feature can be used independently by other required classes. With this principle, we can maximize code reuse, function reuse, and module reuse.

After talking about some basic design principles, let's take a look at Bob's five principles mentioned in Agile Software development design [1], namely, S.O.L. I. D.

The S.O.L. I. D Principle integrates the basic principles and proposes more feasible methods.

SRP (Single Responsibility Principle)

Single Responsibility Principle: For a class, there should be only one reason for its change. If a class has too many responsibilities, these responsibilities are coupled. A change in a role may weaken or suppress the class's ability to complete other duties. This principle is not only applicable to the design of classes, but also to the design of interfaces and modules.

OCP (Open-Closed Principle)

Open-closed principle: software entities (classes, modules, etc.) should be extensible, but cannot be modified. Only by complying with the OCP principles in design and development can the chain reaction be avoided after the new functions are added. OCP focuses on flexibility: function changes are made by adding code, rather than modifying existing code. In general, OCP isolates the changes of the same type by integrating ISP (interface separation principle) and creation abstraction. LSP makes this goal possible.

LSP (Liskov Substitution Principle)

Rys replacement principle: child types must be able to replace their base types.

ISP (Interface Segregation Principle)

Interface separation principle: Do not force the class to implement the methods it does not need. If an interface contains many small and unrelated methods, this interface must be grouped and then separated into multiple interfaces, the class that implements the interface is just the method required to implement it. At the same time, this also reflects that in the design, we should try to comply with the SRP (single responsibility principle ).

DIP (Dependency Inversion Principle)

Dependency inversion principle: High-Level modules should not depend on low-level modules, both of which should depend on abstraction; abstraction should not depend on details, and details should depend on abstraction. A high-level module is a part of the system that does not change frequently. It is an important indicator that distinguishes a system from other systems. It includes System Policy Selection and business model. A low-level module is a part of the system that frequently changes.