Mp.weixin.qq.com/s?src=11&ti…
UML and sequence diagrams
Unified Modeling Language (UML) is an off-patent third generation Modeling and specification Language. UML is an open method for illustrating, visualizing, building, and writing artifacts of an under development, object-oriented, software-intensive system. UML represents a set of best engineering practices that have been proven for modeling large-scale, complex systems, especially at the software architecture level.
We will explain the components of UML diagram construction from the following figure:
Class Diagram: The Class diagram represents a system by showing its classes and the relationships between these classes. Class diagrams are static – they show you what can have an impact but don’t tell you when. For example: animals, birds, ducks, geese, these are all class diagrams. Classes are represented by a delimited rectangle containing the class name, property (field), and method (method). For example, there are methods of reproduction under animals.
So what do we mean by the plus and minus signs before property/method names? They represent the visibility of this property or method, and there are three notations for visibility in UML class diagrams:
+ : indicates public
– : indicates private
# : protected (friendly)
Thus, the animal class in the figure above has two public methods and one property. In fact, the full representation of an attribute looks like this:
Visibility Name: Type [= default]
The contents in parentheses are optional, such as under Controller in a Spring project:
What constitutes the representation of relationships between classes?
1. Dependencies
In UML class diagrams, dependencies are represented by a dotted line with an arrow. Animals, like the one above, depend on air and water to live.
2. Inheritance
The inheritance relationship corresponds to the extend keyword, which is represented in the UML class diagram as a straight line with a hollow triangle. Like the one above, ducks inherit birds, birds inherit animals.
3. Combinatorial relationships
The biggest difference between combinatorial relation and aggregation relation is that the “part” here ceases to exist without the “whole”. In a UML class diagram, composition relationships are represented by a straight line with solid diamonds and arrows pointing to “parts.” In the picture above, for example, the bird is whole and the wing is part. Without the wing, the bird would not exist.
4. Aggregation
From the figure above, we can see that aggregation relationships in UML are represented by straight lines with hollow diamonds and arrows. The aggregation relation emphasizes that “whole” contains “part”, but “part” can exist independently from “whole”. For example, in the picture above, the big geese group contains the wild geese. Without the big geese group, it can also be said to be a wild goose, which can exist alone.
5. Relationships
One-way associations are represented by a straight line with an arrow in a UML class diagram. For example, penguins laying eggs is correlated with climate, and it’s a one-way correlation.
6. Interface implementation relationship
This relationship corresponds to the Implement keyword and is represented by a dashed line with a hollow triangle in the UML class diagram. For example, in the picture above, the geese realize the interface function of flying.
Practical:
IDEA compiler, which automatically generates UML Diagrams as follows: In the concrete class, right-click and select the Diagrams option, and then select Show Diagrams.
Sequence Diagram, also known as Sequence Diagram, Sequence Diagram, is a KIND of UML interaction Diagram. It shows dynamic collaboration between multiple objects by describing the chronological order in which messages are sent between them. There are seven elements involved in drawing sequence diagrams: Actor, Object, LifeLine, Activation, Message, self-associated Message, and composite fragment. Below, from the web:
Practical:
IDEA compiler needs to be installed, SequenceDiagram generation tool: SequenceDiagram. Detailed usage documentation, refer to:
https://plugins.jetbrains.com/plugin/8286-sequencediagram
To operate, right click and select SequenceDiagram.
02
Overview of six design pattern principles
There are six principles of design patterns
1. Open and close principle OCP
The open closed principle says open for extensions, closed for modifications. When the program needs to be extended, it cannot modify the original code, which is also to make the program more expansible, easy to upgrade and maintenance.
2. The Richter substitution principle LSP
If you replace a base class object with a subclass object in software, the program will not generate any errors or exceptions, and vice versa. If a software entity uses a subclass object, it must not use a base object. The reefer substitution principle is: in the program as far as possible to use the base class type to define the object, and at run time to determine the subclass type, with the subclass object to replace the parent class.
3. Principle of Inversion of control IOC
Programming for interfaces relies on abstraction rather than concrete
4. Interface isolation principle ISP
Using multiple isolated interfaces is better than using a single interface
5. Demeter’s rule DP
One entity should interact with other entities as little as possible so that the functional modules of the system are relatively independent
6. Principle of composite reuse
Try to use composition/aggregation rather than inheritance
Three key words in the design
1. Abstraction
To extract common and essential features from numerous things and abandon non-essential features is abstraction. The process of abstraction is also a process of clipping, which is different when it comes to abstraction, depending on the Angle from which it is abstracted. The perspective of abstraction depends on the purpose for which the problem is analyzed.
2. Implementation
The concrete implementation given by an abstract class is realization.
An instance of a class is an instantiation of that class, and a concrete subclass is an instantiation of its abstract superclass.
3, decoupling
This is important. We often talk about code as “high cohesion, low coupling”. So what is coupling?
Coupling is a strong correlation between the behaviors of two entities. And removing the strong link between them is decoupling. Decoupling refers to decoupling the coupling between abstraction and realization, or changing their strong relationship into a weak one.
Strong associations are those that are determined at compile time and cannot be dynamically changed at run time. Weak associations are those that can be dynamically determined and changed at run time. From this definition, inheritance relationships are strong and aggregation relationships are weak.
03
Open closed principle/dependency inversion principle/single responsibility principle
1. Open and close principle
Definition: SOFTWARE entities such as classes, modules, and functions should be open to extension, closed to modification, framed with abstraction, and extended with implementation details.
Advantages: improve the reusability and maintainability of software system.
1.1 the actual combat
The code structure is as follows:
One explanation: ICourse is an abstraction, while JavaCourse and JavaDiscountCourse are implementation details. Test is the topmost, caller.
Specific code reference:
2. Dependency inversion principle
Definition: a high-level module should not depend on a low-level module, both should depend on its abstraction, abstraction should not depend on details; Details should depend on abstractions.
Pros: Program for interfaces, not implementations.
This principle, similar to dependency injection in Spring, calls between service layers that don’t depend on implementation details, just inject the Service interface. In this case, Geely is a low-level module, and this class calls a course that does not rely on a specific implementation but ICourse. Test is the topmost, caller.
3. Principle of single responsibility
Definition: Do not have more than one cause of a class change. A class/interface/method has only one responsibility.
Advantages: Reduced class complexity, improved readability, improved system maintainability, and reduced risk caused by changes.
Disadvantages: Resulting in very large class interfaces, emphasis and balance. For example, you can separate transactions from non-transactions; Or eat (a lot of them together) or drink (a lot of them together).
04
Interface isolation principle/Demeter principle/Richter substitution principle
4. Interface isolation principle
Definition: with multiple specialized interfaces rather than a single master interface, a client should not rely on interfaces it does not need. A class’s dependency on a class should be based on the smallest interface; Create a single interface, not a large and bloated interface. Try to refine the interface and have as few methods in the interface as possible.
The methods of the IAnimalAction interface are split into three different methods. This principle is similar to the single responsibility principle, but single responsibility is about responsibility, while this one focuses on isolation. The drawback of this principle also leads to an explosion of interfaces and implementations, so it also requires attention and balance, which generally undermines this principle.
5. Demeter principle
Definition: An object should have minimal knowledge of other objects. Also known as the least know principle. Minimize coupling between classes.
Advantages: Reduced coupling between classes.
If the Boss wants to know what course or open a course, he does not need to do it by himself. The Boss can give an order to the TeamLeader, which will be implemented by the project leader.
6. Richter’s substitution principle
Definition: If for every object o1 of type T1 there is object O2 of type T2, such that the behavior of all programs P defined by T1 does not change when all objects o1 are replaced by O2, then type T2 is a subtype of type T1.
Definition extension: if a software entity applies to a parent class, it must apply to its subclasses. All references to the parent class must transparently use the objects of the subclass, and the subclass objects can replace the objects of the parent class without changing the logic.
A subclass can extend the functionality of its parent class, but cannot change the functionality of its parent class.
Implication 1: A subclass can implement abstract methods of its parent class, but cannot override non-abstract methods of its parent class.
Meaning 2: Subclasses can add their own unique methods.
Implication 3: When a method of a subclass overrides a method of a parent class, the method’s preconditions (i.e., the method’s input/output) are looser than the input parameters of the parent method.
Implication 4: When a subclass’s method implements a parent class’s method (overriding/overloading or implementing an abstract method), the method’s postcondition (that is, the method’s output/return value) is stricter or equal to that of the parent class.
Note: method inputs and inheritance relationships.
Advantages: constraint inheritance overflow, an embodiment of the open and closed principle; Enhance the robustness of the program, while changing can also be very good compatibility to improve the maintenance of the program, scalability. Reduce risks introduced when requirements change.
Usage scenario: Use this principle when maintaining legacy code.
Conclusion:
When you’re writing code, think about it and follow these principles.