Easy introduction to UML (3)-SRP cook well, let others program, uml-srp

Easy introduction to UML (3)-SRP cook well, let others program, uml-srp
A cook can make a good dish. Maybe he graduated from New Oriental or the secret recipe of his family. It is simple, happy, and efficient for you to let him cook a table of food. However, programming will become an annoyance and hard nut to crack. Maybe this metaphor is not very appropriate, but for every class, they are like an actor, maybe a cook or a driver. They should focus on their own fields, this will be more efficient and concise. From this idea, we have discovered the SRP principle, that is, the single responsibility principle.
There shoshould never be more than one reason for a class to change
Now that we are getting started with UML, we cannot skip the topic. While discussing the SRP principle, we use an instance and use a UML class diagram to represent it. Although it is easy to say, there are still many problems in the actual project, such as how to divide responsibilities (originally an unquantifiable concept ). When discussing whether a class meets the SRP principle, we can think about whether the class changes for one reason, that is, other reasons cannot cause the class to be modified. In the j2ee MVC (Model View Controller) development mode, we know that the Model layer is only responsible for business logic, the View is only responsible for page display, and the Cotroller is only responsible for data transmission. Except for the page change, any other changes will not cause changes to the View-Layer Code. This is the SRP principle. In java's Object-oriented thinking, we can also find the shadows of the SRP principle, such as the three main features of object-oriented: inheritance, encapsulation, and polymorphism. Next we will discuss how to implement the SRP principle at the code layer with examples.
1. Use interfaces to meet the SRP Principle
First, we define a Person class, which is actually the cook. But the boss asked him not only to cook but also to program, so this class is represented by UML

Of course, it seems that this class is not very complicated because it does not have many methods. Here we just demonstrate it. First of all, the definition of this class has a defect: we do not clearly know what the function of this class is, and it has lost its features as a cook. We can use interfaces to implement

Now we carefully analyze the functions of Cooker and Coder interfaces. In the Cooker interface class, we can define all cooking methods, including Lu, Sichuan, and Guangdong. If this cook is more advanced and has learned Hunan cuisine, we only need to add the corresponding method to Cooker and it will not cause any changes to the Coder class, reflecting encapsulation. However, this example can also be used to indicate:

In this example, both methods are feasible. We can think like this: if this cook graduated from New Oriental, every New Oriental graduation course would be similar. In this way, we can define a Cooker interface. As long as it is implemented by the person who graduated from New Oriental, it will be considered as Sichuan cuisine. If you use the second method, you need to define N classes and then write a Sichuan food method in each class. This is redundant and inefficient. In addition, if one of the chefs learned to Drive a car one day, we only need to implement the Drive interface. In fact, this is also the difference between java relay and interfaces. we actually define a template through the interface, and the methods in the interface are known in most cases, so we can dynamically modify the method using the reflection method. 2. Using interfaces, we can better implement polymorphism and pass interfaces as parameters. 3. We can implement multi-inheritance that cannot be implemented by General inheritance. For more information about the benefits of the API, see the example in http://blog.csdn.net/rocketboy911/article/details/1633414.
2. Use inheritance to implement the SRP Principle
In the previous section, we discussed the differences between inheritance and interfaces. In this section, we will discuss how to use inheritance to implement the SRP principle. The blogger is really funny and self-contradictory. Otherwise, the inheritance here refers to the inheritance of the Parent and Child classes, rather than the inheritance of methods. Let's review the previous knowledge and sort out the ideas: all the students who graduated from New Oriental will go to Sichuan cuisine. Then we will say that we will use interfaces instead of inheritance here. If we put the cooks and programmers together, they are all persons. Here we will use inheritance instead of interfaces. Here we forget the unlucky Cook first. We first define a Student class which has three methods: read (), dance (), and sing:


However, we found that although every student could read books, not all of them could dance, and some of them were still incomplete. Let's say that there is still a problem with this class. We can use inheritance to modify this class:


So we can clearly see: Oh! Lee can sing while David can dance. At the same time, they all inherit the Student's read () method and become a versatile Student. In addition, if we want to change the sing () code in the future, we don't need to modify the entire Student code as before. We just need to modify part of Lee to be OK.
3. SRP persistence
This example is from the UML for java program book. I don't know much about it. I will put it here first.


(Spelling error on the left, from the book) the dependency between the Employee and the persistence is illustrated on the left. The change of Persistable will change the Employee more or less, which is not allowed. However, the persistence requirement always exists. Therefore, we can use the structure on the right to separate the relationship between Employee and Persistable and implement the SRP principle.


What are the full names and meanings of SRP, OCP, LSP, DIP, and CARP in uml?

The full name of OOA, Object-Oriented Analysis, Object-Oriented Analysis method (1) enhanced understanding of problem domains and system responsibilities; (2) improved communication between various personnel related to Analysis; (3) strong adaptability to changes in requirements; (4) Support for software reuse; (5) consistency throughout the entire software life cycle. (6) practicality; (7) conducive to user participation. The full name of OOD is the Object-Oriented Design object-oriented Design method. Meaning: it is to further standardize the OOA analysis results so that they can be directly accepted by OOP. Object Oriented Programming Object-Oriented Programming (OOP) is a computer Programming architecture that greatly reduces the difficulty of software development and simplifies Programming. The full name of SOA is service-oriented architecture. It is an architecture model. The key to SOA is service. The idea of development is to split functions into components first, then, package these components with services for system terminals. Special Resource Point, full name of SRP, single responsibility principle significance: using a single responsibility principle can eliminate coupling and reduce the odor of code Rigidity caused by demand changes. The full name of OCP is Open-Closed Principle. It indicates that software bodies should be Open to extensions and should be Closed to modifications. Extend a specific method to implement the previously defined interface without modifying the original class file. The full name of LSP, Liskov Substitution Principle, is the Principle of full replacement. It ensures the system or sub-system has good scalability and can be bound during runtime to ensure the smooth development of object-oriented polymorphism; it facilitates implementation of contractual programming. The full name of DIP Dependence Inversion Principle the Principle of dependency Inversion is significant: Make the details and policies depend on abstraction, and the stability of abstraction determines the stability of the system. The full name of CARP is Composite/Aggregate Reuse Principle synthesis/aggregation Reuse. It means to include existing objects into new objects and make them part of new objects, so that new objects can call the functions of existing objects.