Five, UML class diagram and five principles-----"Big Talk design mode"

I. Single principle of responsibility

As far as a class is concerned, there should be only one cause for it to change.

If a class takes on too much responsibility, it is tantamount to coupling these responsibilities, and a change in responsibility may weaken or inhibit the ability of the class to perform other duties. This coupling leads to the fragility of his design, and when the changes occur, the design suffers unexpected damage; much of what software is designed to do is find responsibility and separate those responsibilities from each other.

Ii. Open-closure principle

Software entities should be extensible, but not modifiable. This principle is the core of object-oriented design, and following this principle can lead to the assertion that object-oriented technology is maintainable, extensible, reusable, and flexible.

The designer must make a choice as to which of the modules he designs should be closed, and must first guess what kind of change is most likely to occur, and then construct abstractions to isolate those changes. It is assumed that changes do not occur when the program was originally written, and when a change occurs, an abstraction is created to isolate the similar changes that occur later, rejecting immature abstractions.

Three, the principle of substitution on the Richter scale

Subtypes must be able to replace their parent types. Because of the substitution of subtypes, modules that use the parent class type can be extended without modification.

Iv. Dependency Reversal principle

The high-level module should not rely on the low-layer module, two should rely on abstraction, abstraction should not rely on the details, detail should rely on abstraction.

To program for the interface, do not program for implementation. This principle can be said to be the object-oriented design of the logo, when writing to consider how to program abstract rather than the details of programming, that is, all the dependencies of the program is terminated in the abstract class or interface.

Five, Di fan principle (least knowledge principle)

If two classes do not have to communicate directly with each other, then these two classes should not have direct interaction, and if one of the classes needs to invoke a method of another class, the call can be forwarded through a third party.

The fundamental idea of this principle is to emphasize the loose coupling between classes, and the weaker the coupling between classes, the more beneficial the reuse, the more weakly coupled class is modified and does not affect the related classes. In the structure design of a class, each class should minimize the access rights of members.

Vi. UML Example diagram

' + ' means public, '-' denotes private, ' # ' denotes protected;

interface at the top of the "interface" display, only two lines; at the same time, another expression method is the lollipop notation;

Aggregation represents a weak ' owning ' relationship, which shows that a object can contain a B object, but the B object is not part of a object;

Synthesis is a strong ' owning ' relationship, which embodies the strict part and the whole relationship, part and the whole life cycle like;

Inheritance relationship	Implementing interfaces	Association relationship	Aggregation relationships	Synthetic relationships	Dependent relationships
Hollow Triangle + Solid Line	Hollow Triangle + Dashed line	Solid line Arrows	Hollow Diamond + Solid line Arrow	Solid Diamond + Solid line Arrow	Dashed arrows

Five, UML class diagram and five principles-----"Big Talk design mode"