Oriented to the design principle and oriented to the design principle

Oriented to the design principle and oriented to the design principle

How to measure software design quality 1

Primary criteria

Meet functional requirements of software

The design that meets the functional requirements of software is not necessarily a good design.

Good Design

Readability: whether software design documents are easily understood by other programmers. The design with poor readability brings serious harm to the development and maintenance of large-scale software.

Reusability: whether the architecture, class, components, and other units of the software system can be easily reused by other parts of the project or other projects.

Scalability: the difficulty of functional or performance scaling when the software is facing changes in demand.

Maintainability: the difficulty of software maintenance (mainly modification of software errors and addition of missing functions.

The above four standards are too abstract to be considered

Cohesion

Coupling Degree

 

What is cohesion

Definition: number and diversity of tasks that a single unit of an application is responsible. Cohesion is related to a single class or a single method unit.

Good software design should be highly cohesive.

Ideally, a code unit is responsible for a cohesive task, that is, a task can be considered as a logical unit. A method should implement a logical operation, and a class should represent a type of entity.

The main reason behind the cohesion principle is reuse. Another advantage of following this rule is that when some aspects of an application need to be changed, we can find all the relevant parts in the same unit.

If a system unit is responsible for only one task, it indicates that the system unit has a high cohesion. If a system unit is responsible for many irrelevant tasks, it indicates that the system unit is of low cohesion.

A Simple Method for Determining cohesion

If a method can be named in the form of a simple verb + noun, or if a class can be named with an accurate noun, such a class or method is a system unit with a high concentration. Otherwise, if the class or method name must contain the words "and", "or" to accurately reflect its functional features, the cohesion of these classes or methods is not high.

 

What is coupling degree?

Coupling Degree indicates the closeness between classes.

The coupling degree determines the ease of changing an application. In the tightly coupled class structure, changing a class will lead to other classes also need to be modified. Obviously, this should be avoided during class design, because small changes will quickly fluctuate and affect the entire application. In addition, it is necessary to find all the places to be modified, which makes modification difficult and time-consuming. In a loosely coupled system, we can change a class without modifying other classes, and the application can still work normally.

 

Design principles

"High Cohesion and low coupling" are common features of all excellent software.

How to do it? Follow certain design principles during design.

 

1) single responsibility

Single Responsibility Principle, SRP

Definition: all objects should have a single responsibility, and all the services it provides only focus on this responsibility.

In other words, for a class, there should be only one reason for its change, and there should never be multiple reasons for its change.

 

Understanding of a single responsibility

To understand the single responsibility principle, we must first understand what is class responsibility. The responsibility of a class is determined by the role of the class object in the system. For example, in the teaching management system, a teacher represents a role, which determines that the teacher's responsibility is teaching. In order to fulfill the teaching responsibilities, teachers need to give lectures and correct homework. The behavior of lectures and correcting homework is equivalent to our method in the program, class methods and attributes are set to fulfill this responsibility.

The single responsibility of a class is that a class should only do one thing. If a method or attribute in a class has nothing to do with its responsibilities, or to fulfill another responsibility, such a design does not conform to the single responsibility principle of the class. The disadvantage of this design is that it reduces the cohesion of classes and enhances the coupling of classes. The problem is that when we use this class, we will bring unnecessary functions to the Code, resulting in a waste of redundant code or code.

 

Single Responsibility Principle

The single responsibility principle puts forward an ideal expectation for the object's responsibilities. Objects should not assume too many responsibilities, just as they should not be divided into two categories. Only focus can ensure the high cohesion of objects; only single can ensure the fine granularity of objects. The high cohesion and fine granularity of objects facilitate the reuse of objects. A large object bears too many responsibilities. When the client needs a responsibility for this object, it has to include all the responsibilities, resulting in a waste of redundant code or code.

The single responsibility principle is also conducive to the stability of objects. The responsibility of an object is always provided to other objects for calling, so as to form the collaboration between the object and the object, thus generating the dependency between the object. The less the responsibilities of objects, the less dependency between objects, the less coupling, and the fewer constraints and constraints of other objects, thus ensuring system scalability.

The single responsibility principle does not require us to define only one responsibility for the object in an extreme way, but uses an extreme expression to emphasize that when defining the responsibility of the object, the relationship between responsibilities and objects must be considered. The responsibility must properly express the behavior of the object, without undermining the beauty of harmony and balance, or even incompatibility. In other words, the single responsibility described in this principle refers to a set of public responsibilities closely related to the object.

 

Ii) principle of opening/closing

The Open-Close Principle (OCP) Principle refers to a software entity (class, module, method, etc.) that should be Open to the extension and closed to the modification.

The modules designed according to the open/closed principle have two basic features:

Open for extension: the module behavior can be extended. When the application requirements change, the module can be extended to meet new requirements.

Closed for modification: you do not need to modify the source code or binary code of a module when extending the module's behavior.

Seemingly conflicting

 

How can we achieve the principle of opening/closing?

The key lies in abstraction.

What is abstraction? Or is it necessary to abstract something as an abstract class or interface?

Abstraction can be divided into two situations:

Abstraction for multiple domains

Abstraction for a single domain

 

Abstraction of Multiple Fields

The common behaviors of a group of objects are abstracted into abstract classes or interfaces, and the implementations of different behaviors are encapsulated in subclasses or implementation classes. An interface or abstract class cannot be instantiated, so modification is disabled. To add a new function, you only need to implement the interface or inherit the abstract class to enable the extension.

Use abstract classes. When designing a class, similar classes with common functions are abstracted. The common functions are put into the abstract class, and different behaviors are encapsulated in the subclass. In this way, you only need to implement a new subclass Based on the abstract class when you need to extend the functions of the system. When extending subclass, you can not only have the common attributes and methods of abstract classes, but also custom attributes and methods.

Interface. Unlike abstract classes, an interface only defines the interface methods that the implementation class should implement, without implementing public functions. In most software development, the interface is defined for the Implementation class, which must be implemented when the subclass is extended. To change the original implementation, you only need to change one implementation class.

 

Single Domain

Encapsulate the behavior that may change in a single domain class, that is, identify the changes that may need to be made in the class and encapsulate them into abstract classes or interfaces, this separates the change point from the code that does not need to be changed.

If every new requirement changes the code of a behavior in a domain class, we can determine that this part of code needs to be abstracted, it is differentiated from other stable code. Extract the changed part and encapsulate it into an abstract class or interface so that it can be easily modified or expanded in the future without affecting other parts that do not need to be changed. The advantage of encapsulating change points is to isolate the frequently-changed parts and stable parts of the class, which helps increase reusability and reduce the Coupling Degree of the system.

 

The principle of opening/closing is the core

The principle of opening/closing is the core of object-oriented design. Following this principle can bring flexibility, reusability, and maintainability. Other design principles (the Lee's replacement principle, the dependency reversal principle, the combination/aggregation Reuse Principle, the Demeter principle, and the interface isolation principle) are the means and tools for implementing the open and closed principles.

 

3) Lee's replacement principle

Definition of The Liskov Substitution Principle (LSP) Principle: In a software system, The subclass should be able to completely replace any place where The parent class can appear, and after replacement, the customer program that calls the parent class will not be changed in behavior.

Significance of the Lee's replacement principle

The Lee's replacement principle is an important guarantee to make the Code conform to the open and closed principle. At the same time, it reflects:

Class inheritance principle: the Lee's replacement principle is often used to check whether two classes are inherited. In the inheritance relationship that complies with the Rys replacement principle, where the parent class code is used, the Child class code can be replaced to correctly execute the action. In other words, if the child class cannot execute the Action correctly after replacing the parent class, the inheritance relationship is incorrect and the relationship between them should be re-designed.

Guarantee of the correctness of the action: The Rys replacement principle restricts subclass. Therefore, when you expand an existing class to create a new subclass, extensions that comply with the Lee's replacement principle do not introduce new errors to existing systems.

The inspiration from the Li's replacement principle

Class inheritance principle: if an object of an inherited class may encounter a running error in the base class, the subclass should not inherit from the base class, or, the relationship between them should be re-designed.

Action correctness guarantee: class extensions that comply with the Li's replacement principle will not introduce new errors to existing systems.

 

4) Principle of dependency reversal

The Dependency Inversion Principle (DIP) Principle is to put the Dependency between two modules into dependent abstract classes or interfaces. It has two meanings:

High-level modules should not depend on low-level modules, both of which should depend on abstraction;

Abstraction should not depend on details. Details (subclass, implementation class) should depend on abstraction.

Inspiration from the principle of dependency reversal

Do not implement programming for the interface. (Program to an interface. not an implementation)

 

5) Principles of combination/aggregation Reuse

Composite/Aggregation Reuse Principle (CARP) means to use combination/Aggregation instead of inheritance as much as possible to achieve Reuse. Another explanation is to use some existing objects in a new object to make it a part of the new object. The new object is reused by entrusting the function to these objects.

In the object-oriented design, there are two ways to reuse existing objects, namely through combination/aggregation or inheritance. So what are the differences in Maintainability between the two reuse methods?

1) Combination/aggregation multiplexing

2) Inheritance Reuse

Advantages of combination/aggregation multiplexing:

1) The only way for a new object to access a component object is through the component object interface.

2) the reuse of such objects is black box reuse, because the internal implementation details of component objects are invisible to new objects.

3) This reuse requires less dependencies.

4) The new object can dynamically reference objects with the same component object type during running.

Inheritance reuse advantages:

1) The new implementation is easier, because most of the functions of the superclass can automatically enter the subclass through the inheritance relationship.

2) It is easier to modify or extend the inherited implementations.

Disadvantages of inheritance reuse:

1) Inheritance reuse destroys packaging. Expose the implementation details of the superclass to the subclass. The internal details of superclasses are often transparent to sub-classes and can be reused in white boxes.

2) The implementation of the superclass has changed, and the implementation of the subclass has to be changed.

3) superclasses inherit from static and cannot be changed during running time. Therefore, there is not enough flexibility.

 

6) interface isolation principles

Interface Segregation Principle (ISP) refers to the Interface that each customer needs instead of relying on the methods they cannot use. In other words, users cannot be forced to rely on interfaces they do not use.

Two meanings of the interface isolation principle (1)

Interface Design principle: the interface design should follow the minimum interface principle, and do not insert unused methods into the same interface. If the method of an interface is not used, it indicates that the interface is too fat and should be divided into several function-specific interfaces, it is better to use multiple dedicated interfaces than to use a single total interface.

Example: Mobile Phone

Two meanings of the interface isolation principle (2)

Interface inheritance principle: If one interface A inherits another interface B, interface A inherits the method of interface B, interface A inherited from interface B should also follow the above principle: it should not contain methods not used by users. Otherwise, it indicates that interface A is contaminated by B and its relationship should be re-designed.

Example: Door

 

7) dimit Law (decoupling)

The Law of Demeter, also known as the "least knowledge principle", defines that a software entity should interact with other entities as little as possible.

Mom said: Don't talk to strangers!

Example: GUI Design