1.2 hardware design patterns Chapter 1 UML knowledge required to learn Design Patterns

To understand the design pattern, you need to understand the classdigraphs and objectdigraphs. The following describes the necessary knowledge of UML so that you can learn the design pattern. Brief Introduction to attributes and operations of a class. Class attributes (attributes), operations (operations), attributes and operations collectively referred to as special

To understand the design pattern, you need to understand Class digraphs and Object digraphs. The following describes the necessary knowledge of UML so that you can learn the design pattern. Brief Introduction to attributes and operations of a class. Class attributes (attributes), operations (operations), attributes and operations collectively referred to as special

To understand the design pattern, you need to understand Class digraphs and Object digraphs. The following describes the necessary knowledge of UML so that you can learn the design pattern.


Properties and operations

This section briefly introduces the attributes and operations of a class.
Classes include attributes, operations, attributes, and actions ).

The class chart details are further detailed, including the attributes and operation scopes, attribute types, parameter types, and method return value types.




Interface, enumeration

Abstract class




Inheritance relationship

Class B inherits Class A, such:

Abstract classes are inherited, such:

Implementation relationship

Implementation refers to the implementation of an interface, rather than the instantiation of a class.
Implementation example:

Dependency

First look at the figure:

B depends on A, indicating that if the interface of A changes, B needs to change accordingly.
Common dependencies are:
1. B calls the method.
2. The A parameter is used in the method B.
3. the return value type of method B is.

Reference relationship

First look at the figure:

Class1 has an arrow pointing to Class2, indicating that Class1 contains Class2 references.
The specific reference method is further clarified: the type of the private variable m_Class2 in Class1 is Class2.

You may ask: if a class maintains the reference of another class, it generally calls the method of another class. Should they be dependent? What is the difference between reference and dependency?
This is a good question! In some cases, a class retains the reference of another class, but this class does not call the method of another class, but exposes the reference of another class for external calls.
For example, if Class1 has a certain attribute Class2, you can access this attribute to obtain the instance of Class2:
Class1 = new Class1 ();
Class2 = class1.Class2;
Although Class1 references Class2, it does not call the Class2 method itself, but allows external users to obtain Class2 instances through familiarity.

However, many documents and books do not fully explain the "dependency" and "reference relationship", and the explanations between different documents are even mutually exclusive. Most of the class diagrams I have seen in design patterns do not distinguish between "dependency" and "reference relationship". Most class diagrams in design patterns are drawn as "reference relationships ", the class diagrams after this book will also draw a reference relationship without any difference between the two ".

"Include" Link

I divide the "include" relationship into "weak include" and "strong include". The above is "weak include", and the following is "strong include ", this figure shows the differences between the two types of content.

"Weak inclusion" and "strong inclusion" are just common examples of me. The academic term is "aggregation" and "Combination". The general information may be confusing to you, I hope you can explain it further.

In the class diagram of the design mode, the "include" relationship is used in many places. Some materials are painted as "strongly contained", and some materials are painted as "weak contained ". I personally think of "strong inclusion" as a special case of "weak inclusion". In most cases, I first draw a picture of "weak inclusion" and convert it to "strong inclusion" if necessary ". The inclusion relationships in this book are all painted as "weak inclusion ".

Object Graph

After the class is instantiated, it is an Object, indicating that the graph of the relationship between these objects and objects is an Object graph. Sometimes it is necessary to use an object graph to represent the design pattern.

Example of an object graph:

Please refer to the following article ......

Author: Zhang chuanbo

Innovation workshop entrepreneurship class (agile course) Instructor

Senior Consultant of software R & D Management

Cmme Chief Expert

Fireball-UML war demand analysis author

Author of Hardware Design Patterns

Founder of www.umlonline.org