Shulou(Shulou.com)06/02 Report--

This article will explain in detail what the UML design principles are, and the editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

Object-oriented Design principle-UML Class Design principle

In object-oriented design, designers pay great attention to how to deal with the changes of design requirements through very small design changes. For this reason, many OO pioneers put forward a lot of object-oriented design principles to guide the design and development of OO. Here are a few design principles related to class design.

1. Opening and closing principle (theOpenClosedPrincipleOCP)

The open-close principle in the UML class design principle means that a module should be open in terms of expansibility and closed in terms of modification. Therefore, interface encapsulation mechanism, abstract mechanism and polymorphic technology should be considered as far as possible in object-oriented design. This principle is also suitable for non-object-oriented design methods, and is one of the important principles of software engineering design methods.

Let's take the example of radio as an example to illustrate the object-oriented opening and closing principle. When we listen to the program, we need to turn on the radio, align the frequency of the radio and adjust the volume. But for different radios, the details of these three steps are often different. For example, the radio of the automatic contraction radio station and the button contraction are not the same in the operation details. Therefore, we are unlikely to achieve these different modes of operation (through overloading) through a radio class for each different type of radio. But we can define a radio interface that provides six abstract ways to turn on, turn off, increase the frequency, lower the frequency, increase the volume, and lower the volume. Different radios inherit and implement these six abstract methods. In this way, the new radio type will not affect other original radio types, and it is very convenient to expand the radio type. In addition, existing radio types will not affect other types of radios when modifying their methods of operation.

Figure 1 is an example of a radio class diagram generated by OCP:

Picture 1OCP App (Radio)

two。 Substitution principle (theLiskovSubstitutionPrincipleLSP)

Subclasses should be able to replace the parent class and appear anywhere the parent class can appear. This principle in the UML class design principle is the design principle proposed by Liskov in 1987. It can also be derived from the concept of BertrandMeyer's DBC (DesignbyContract).

Let us take students as an example. Night school students are a subcategory of students, so night school students can appear wherever students can appear. This example is a bit far-fetched. An example that reflects this principle is the circle and the ellipse. The circle is a special subclass of the ellipse. So wherever there is an ellipse, a circle can appear. But the reverse may not work.

The related diagram of Liskov is shown in figure 2:

Graph 2Liskov principle

When using the substitution principle, we try to design class B as an abstract class or interface, and let class C inherit class B (interface B) and implement operation An and operation B. when running, class C instances replace B. in this way, we can extend the new class (inheritance class B or interface B) without modifying class A.

3. Dependency principle (theDependencyInversionPrincipleDIP)

When designing a business, dependencies related to a particular business should rely on interfaces and abstract classes as much as possible, rather than on concrete classes. The specific class is only responsible for the implementation of the related business, and modifying the specific class does not affect the dependency relationship related to the specific business.

In the structured design, we can see that the underlying module is the implementation of the high-level abstract module (the high-level abstract module calls the low-level module), which shows that the abstract module depends on the module related to the concrete implementation. when the concrete implementation of the underlying module changes, it will seriously affect the high-level abstract module, which is obviously a "hard wound" of the structured method.

The dependency of the object-oriented approach is just the opposite, and the concrete implementation class depends on abstract classes and interfaces (see figure-3).

For this reason, when we design the business, we should try to define the prototype of the business method in the interface or abstract class, and implement the business method through the concrete implementation class (subclass). The modification of the content of the business method will not affect the call of the business method at run time.

Fig. 3 illustration of dependency principle

4. Interface separation principle (theInterfaceSegregationPrincipleISP)

It is better to use multiple interfaces related to specific customer classes in the UML class design principle than to use a common interface that covers multiple business methods.

The ISP principle is another enabling technology that supports componentization such as COM. Without ISP, the availability and portability of components and classes will be greatly reduced.

The nature of this principle is quite simple. If you have a class for multiple customers, creating a specific business interface for each customer and then having that client class inherit multiple specific business interfaces will be more efficient than loading all the methods the customer needs directly.

Figure 4 shows a class with multiple customers. It serves all customers through a huge interface. As long as the approach to customer A changes, customer B and customer C will be affected. Therefore, you may need to recompile and publish. This is an unfortunate practice.

Figure 4 Service class with integrated interface

Let's take a look at the technology shown in figure-5. The methods required by each specific customer are placed in specific interfaces that are inherited and implemented by the Service class.

Figure 5 Service class design using interface separation

If the approach to customer A changes, customer B and customer C will not be affected and will not need to be recompiled and rereleased.

This is the end of this article on "what are the UML design principles?". I hope the above content can be helpful to you, so that you can learn more knowledge. if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.