Design principles for a pair of images

How to measure software design quality 1

The first standard

Meet the functional requirements of the software

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

Good design.

Readability: Software design documents are easily understood by other programmers. The poor readability of the design will bring serious harm to the development and maintenance process of large-scale software.

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

Scalability: How easy it is to expand functionality or performance as the software faces changes in demand.

maintainability: Software maintenance (mainly refers to software error modification, omission of the function of the addition, etc.) of the ease of the degree.

The above four standards are too abstract to be considered

Internal cohesion Degree

Coupling degree

What is the cohesion degree

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

Good software design should achieve high cohesion.

Ideally, a unit of code should be responsible for a cohesive task, meaning that a task can be thought of 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 aspect of an application needs to be changed, we can find all the relevant parts in the same unit.

If a system unit is responsible for only one thing, it means that the system unit has a high degree of cohesion; If a system unit is responsible for a lot of unrelated things, it means that the system unit is very low in cohesion.

A simple method of judging the cohesion degree

If a method can be named in the form of a simple verb + noun, or if a class can be named with an exact noun, then such a class or method is a system unit with a higher degree of cohesion, and conversely, if the name of the class or method must contain the words "and", "or" to accurately reflect its functional characteristics, The cohesion of these classes or methods must not be high.

What is coupling degree

The coupling degree represents the tightness of the relationship between classes.

The degree of coupling determines how easy it is to change an application. In a tightly coupled class structure, changing a class causes other classes to be modified as well. Obviously, this is what we should avoid in class design, because tiny changes can quickly fluctuate and affect the entire application. In addition, it is necessary to find all the places that need to be modified, which in fact makes the changes difficult and time consuming. In loosely coupled systems, we can change a class without having to modify other classes, and the application will still work.

Design principles

"High cohesion, low coupling" is a common feature of all good software.

How do you do that? Design in accordance with certain design principles.

A) Single responsibility

Single Responsibility PRINCIPLE,SRP

Definition: All objects should have a single responsibility, and all of the services it provides are only around this responsibility.

In other words: A class should have only one cause for it to change, never allow a class to have multiple reasons for change.

Understanding of a single responsibility

To understand the principle of single responsibility, we must first understand what is the duty of the class. The responsibility of the class is determined by the role of the object of the class in the system. For example, in the teaching management system, the teacher represents a role, which determines that the teacher's role is teaching. To complete the duties of teaching, teachers need to teach, correcting homework, and lectures, correcting the action is equivalent to our methods in the program class, the method and properties of the class is to complete this responsibility set.

The single function of a class is to say that a class should do only one thing. If a method or property in a class has nothing to do with the responsibility it is going to accomplish, or to accomplish another function, then such a design does not conform to the single principle of responsibility of the class. The disadvantage of this design is to reduce the cohesion of the class and enhance the coupling of the class. The problem with this is that when we use this class, we bring the functionality that we didn't need into the code, which can lead to a waste of redundant code or code.

Thinking on the principle of single duty

The principle of single responsibility puts forward an ideal expectation of the object's responsibility. Objects should not assume too much responsibility, just as one should not be divided into two. Only by focusing can we guarantee the high cohesion of the object, only a single one can guarantee the fine granularity of the object. The high cohesion and fine granularity of objects facilitates the reuse of objects. A large object takes on too much responsibility, and when the client needs a certain responsibility for the object, it has to include all of its responsibilities, resulting in a waste of redundant code or code.

The principle of single responsibility also contributes to the stability of the object. The object's responsibilities are always to be provided to other object invocations, thus forming the object-to-object collaboration, resulting in dependency between objects. The less the object's responsibilities, the fewer dependencies between objects, the less coupling, and the less constraints and containment of other objects, thus guaranteeing the scalability of the system.

The principle of single responsibility does not require that we define only one responsibility for an object, but rather to use extreme representations to emphasize that the relationship between responsibilities and objects must be considered when defining object responsibilities. Responsibility must properly represent the behavior of the object, without undermining the beauty of harmony and balance, or even being incompatible. In other words, the single responsibility described by the principle refers to a set of responsibilities that are in the open and closely related to the object.

II) opening and closing principle

The open and closed principle (Open-close Principle, OCP) refers to a software entity (class, module, method, etc.) that should be opened to the extension and shut down for modification.

Modules designed to follow the open and closed principle have two basic features:

For the extension is open (open for extension): The behavior of the module can be extended, when the requirements of the application change, the module can be extended to meet the new requirements.

The change is closed (Closed for modification): You do not have to change the module's source code or the binaries when you extend the module behavior.

Seems contradictory to each other

How to realize open and close principle?

The key is abstraction.

What exactly should be abstracted? Or should we abstract something into an abstract class or interface?

Abstraction is divided into two situations:

Abstraction of multiple domain classes

Abstraction of a single domain class

Abstraction of multiple domain classes

The common behavior of a group of objects is abstracted into an abstract class or interface, and the implementation of different behaviors is encapsulated in subclasses or implementation classes. An interface or abstract class cannot be instantiated, so it is closed for modification, and adding new functionality is open to expansion by simply implementing an interface or inheriting an abstract class.

Use abstract classes. When you design a class, you abstract the similar classes that have common functionality, put the common functional parts into the abstract class, and encapsulate the different behaviors in the subclasses. In this way, when the system needs to be extended, only the new subclass can be implemented according to the abstract class. When you extend a subclass, you can have not only the common properties and common methods of the abstract class, but also the custom properties and methods.

Use an interface. Unlike abstract classes, an interface defines only the interface methods that an implementation class should implement, without implementing public functionality. In most software development now, the interface is defined for the implementation class, so that the interface must be implemented when the subclass is extended. If you want to change the original implementation, you only need to change an implementation class.

Single Domain class

Encapsulate the behavior that may change in a single domain class, that is, to find out where the class might need to change and encapsulate it as an abstract class or interface, separating the point of change from the code that does not need to change.

If each new requirement comes with a change in the code for one of the behavior of a domain class, then we can be sure that this part of the code needs to be abstracted and differentiated from other stable code. Take the changed part out and encapsulate the abstract class or interface so that it can be easily changed or expanded in the future without affecting the rest of the parts that do not need to change. The advantage of the package change point is that it isolates the frequently changing parts of the class from the stable ones, helping to increase reusability and reducing system coupling.

The opening and closing principle is the core

The opening and closing principle is the core of object-oriented design. Following this principle leads to flexibility, reusability, and maintainability. Other design principles (the Richter replacement principle, the dependency reversal principle, the combination/aggregation multiplexing principle, the Dimitri rule, the Interface isolation principle) are the means and tools to realize the open and closed principle.

III) The principle of the Richter replacement

The definition of the Richter replacement principle (the Liskov Substitution principle,lsp): In a software system, subclasses should be able to completely replace any parent class that can appear, and after substitution, the client program that invokes the parent class will not have any change in behavior.

The significance of the principle of the Richter replacement

The Richter replacement principle is an important guarantee that the code conforms to the open and closed principle, while it embodies:

Class inheritance principle: The Richter substitution principle is commonly used to check whether two classes are inheritance relationships. In an inheritance relationship that conforms to the Richter scale substitution principle, where the parent code is used, the child class code is substituted to correctly perform the action processing. In other words, if the subclasses are not able to perform the actions correctly after replacing the parent class, their inheritance is incorrect and the relationship between them should be redesigned.

Action Correctness Assurance: The Richter Substitution principle constrains the sub-class, so extending the existing class to create a new subclass, an extension that conforms to the Richter scale does not introduce new errors to the existing system.

The revelation of the principle of substitution on the Richter scale

The inheritance principle of a class: If an object of an inheriting class might run in the presence of a base class, the subclass should not inherit from that base class, or the relationship between them should be redesigned.

Action Correctness Assurance: A class extension that conforms to the Richter substitution principle does not introduce new errors into existing systems.

IV) reliance on reversal principle

The dependency reversal principle (Dependency inversion Principle, referred to as dip) refers to the inversion of dependencies between two modules as dependent abstract classes or interfaces. There are two layers of meaning:

High-level modules should not be dependent on low-layer modules, both should be dependent on abstraction;

Abstractions should not be dependent on detail, and details (subclasses, implementation classes) should be dependent on abstraction.

The revelation of relying on the reversal principle to us

To program for the interface, do not program for implementation. (Program to an interface. Implementation)

V) Combination/aggregation multiplexing principle

The combination/aggregation multiplexing principle (composite/aggregation reuse principle,carp) refers to the use of combination/aggregation rather than inheritance to achieve reuse purposes. Another explanation is to use some existing objects in a new object to make them part of the new object, and the new object to reuse the objects by delegating the functionality to those objects.

In object-oriented design, there are two ways to achieve the purpose of reusing existing objects, either by combining/aggregating, or by inheriting. So what is the difference between these two different ways of multiplexing in terms of maintainability?

1) combination/aggregation multiplexing

2) Inheritance Reuse

Benefits of combination/aggregation multiplexing:

1) The only way to access an ingredient object from a new object is through the interface of the Component object.

2) Reuse of such objects is a black-box reuse because the internal implementation details of the constituent objects are invisible to the new object.

3) This multiplexing uses less reliance.

4) New objects can be dynamically applied to objects of the same composition object type at run time.

Benefits of Inheritance Reuse:

1) The new implementation is easier because most of the functionality of the superclass can be automatically entered into subclasses through inheritance relationships.

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

Disadvantages of inheritance reuse:

1) inherit and reuse the damaged package. Exposes the implementation details of a superclass to subclasses. The inner details of the superclass are often transparent to the sub-class and reused in white boxes.

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

3) The superclass inherits from the static and cannot be changed during the run time. Therefore, there is not enough flexibility.

VI) Interface Isolation principle

The interface isolation principle (Interface segregation Principle, referred to as ISP) means that customers should not rely on the methods they cannot use, only to give each customer the interface it needs. In other words, you cannot force users to rely on interfaces that they do not use.

Interface Isolation principle two-tiered meaning (1)

Interface design principles: The design of the interface should follow the minimum interface principle, do not use the method is not used by the user to plug into the same interface. If the method of an interface is not used, it means that the interface is too fat and should be split into several functionally-specific interfaces, and using multiple specialized interfaces is better than using a single total interface.

Example: Mobile

Interface Isolation principle two-tiered meaning (2)

Interface Inheritance principle: If an interface a inherits another interface B, then interface A is equivalent to the method that inherits the interface B, then interface a inherits the interface B should also follow the above principle: should not contain the method that the user does not use. Conversely, interface A is contaminated by B, and the relationship should be redesigned.

Example: Door

VII) Dimitri Law (decoupling)

The Dimitri rule (law of Demeter, or Lod), also known as the "least knowledge principle", is defined as: a software entity should interact with as few interactions as possible with other entities.

Mother said: Don't Talk to strangers!

Example: Design of the GUI

Design principles for a pair of images