The object-oriented design principle of ooad

Learning This design pattern really feel very abstract, only own a lot of understanding!

In a lot of times, a lot of knowledge will feel very contradictory to speak up.

This chapter aims

1 Mastering the concept of cohesion and coupling degree

2 Mastering Object-oriented design principles

(a) How to measure the quality of software design

Cohesion: 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. (In my own understanding, you do all of your tasks in a class, and these tasks are in your own class.) ）

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.

Design principles:

"High cohesion and low coupling" is

Certain design principles that are followed at design time:

1

Design Principle Name	Introduction to design principles	Importance
Single principle of responsibility	Classes have a single responsibility and cannot put too much responsibility in one class.	★★★★☆
Opening and closing principle	The software entity is open to the extension, but it is closed for modification, that is, to extend its functionality without modifying a software entity.	★★★★★
The principle of the Richter replacement	In a software system, a subclass object can be accepted where a base class object is acceptable.	★★★★☆
Dependency reversal principle	Instead of programming for specific classes, you should program for the abstraction layer.	★★★★★
Interface Isolation principle	Use multiple specialized interfaces instead of one unified interface.	★★☆☆☆
Combination/Aggregation Multiplexing principle	In the system, you should use as many combination and aggregation associations as possible, and use less or no inheritance relationships.	★★★★☆
Dimitri Law	The fewer references a software entity has to other entities, the better, or if two classes do not have to communicate directly with each other, then these two classes should not have a direct interaction, but indirectly by introducing a third party.	★★★☆☆

One: Single Responsibility Principle:

Single Responsibility PRINCIPLE,SRP definition: All objects should have a sole responsibility, and all of the services it provides are only around this responsibility. (For a class, there should be only one reason for it to change, never to have multiple reasons for a class to change.) Understanding of a single responsibility: eg: in your class, he is a property, there are some methods, then his duty is not a single, he has to act as a design attribute, but also as the design of the method. So generally in a class, there are only attributes, even if there are methods that only have the Getter,setter method. Write the method in an interface. Thinking on the principle of single duty: 1: The single duty principle puts forward an ideal expectation of the object's responsibility. 2: The principle of single responsibility is also conducive to the stability of the object. 3: The single responsibility principle 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. (It's a bit of a contradiction!) Second: Open and close principle: the opening and closing principle (Open-close Principle, abbreviation OCP) refers to a software entity (class, module, method, etc.) should be opened to the extension, the modification is closed. The modules designed to follow the open and closed principle have two basic features: for the extension to be opened (for extension): The behavior of the module can be extended, and 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. How to realize open and close principle? The key is that abstraction is abstracted into two situations: abstraction for multiple domain classes:the common behavior of a group of objects is abstracted into an abstract class or interface, and the implementation of a different behavior is encapsulated in a subclass or implementation class。 An interface or abstract class cannot be instantiated, so it is closed for modification, and adding new functionality enables the use of abstract classes for extended openness by simply implementing an interface or inheriting an abstract class: When designing a class, abstract processing of similar classes with common functionality, and putting common functional parts into abstract classes, Instead, the different behaviors are encapsulated in 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. Interfaces: Unlike abstract classes, an interface defines only the interface methods that the 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.  Eg: annual salary employees (expressed in salary class), hourly paid employees (denoted by the hourly class), and contractors (represented by the contractor Class) Act in common: calculate a pay-by-mail cheque to create an abstract class: Employee has attributes: id,name,address;   There are methods: Computepay,mailheck, build three classes: Salary,hourly,contractor, inherit abstract class employee, have own property, calculate compensation method. The abstraction of a single domain class encapsulates the potentially changing behavior of a single domain class, which 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.

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.

The knowledge of ooad theory is many, the practice is comparatively few. Understanding is really more abstract, sometimes speaking of knowledge is also feeling contradictory.

Continue with other principles tomorrow ...

The object-oriented design principle of ooad