Graphical Design Patterns - What You Need to Know Before Learning Design Patterns
Before learning design patterns, let's learn a few little knowledge to better understand design patterns
Design patterns are not class libraries
In order to write object-oriented programs conveniently, we use class libraries, but design patterns are not class libraries.
Design patterns are a very general concept compared to class libraries. The class library is a component composed of programs, and the design pattern is used to express how the internal components are assembled, and how each component is related to each other to form a huge system.
Let us consider the story of Snow White as an example. When telling the outline of the story, we don't need to know who is playing Snow White and who is playing the prince in the power of interpreting the story. Telling about the "relationship" between Snow White and the prince is more important than introducing the actors. Because the "Snow White" played by a specific actor is not Snow White, no matter who plays this role, as long as they perform according to Snow White's script, they are Snow White. What is important is who are the characters in the story and what is the relationship between them.
Design patterns are the same. When answering "what is abstract factory mode", reading specific sample code helps us understand the answer, but not only such specific code is abstract factory mode. What matters is what classes and interfaces are in this code and what is the relationship between them.
But the design pattern is used in the class library
Design patterns are not class libraries, but there are many design patterns used in many standard class libraries. Mastering design patterns can help us understand the role played by these class libraries.
A typical example is as follows, and we will learn further in the chapters that introduce various design patterns separately:
- java.util.Iterator is an interface used to traverse a collection of elements, and the iterator mode is used here
- java.util.Observer is an interface used to observe the state changes of objects, and the Observer mode is used here
- There are many other factors that use the factor method pattern: the getInstance method of the java.util.Calendar class, the getInstance method of the java.secure.SecureRandom class, and the getInstance method of the java.text.NumberFormat class
- The Composite pattern is used in the two classes java.awt.Component and java.awt.Container
Sample programs are not finished products
One of the goals of design patterns is to increase program reusability; that is, design patterns consider how programs can be reused as "components." Therefore, the sample programs should not be considered finished products, but rather as a basis for extensions and changes.
- What functions can be extended
- What must be modified when extending the function
- Which classes do not need to be modified
Looking at design patterns from the above perspective can help us deepen our understanding of design patterns
Not just looking at pictures, but understanding pictures
Next, the design pattern will be explained graphically, and the main ones used are class diagrams and sequence diagrams (for details, please refer to UML). These diagrams are not just simple drawings, the content of which cannot be understood with just a glance.
When looking at a class diagram, first look at the rectangles (classes), then look at the methods in them, and confirm which are ordinary methods and which are abstract methods. Then confirm the direction of the arrows between the classes to figure out which class implements which interface. Only by proceeding step by step like this and digging into the contents of the picture step by step can we truly understand the main idea of the picture.
Sequence diagrams are easier to understand than class diagrams. By confirming which object calls which object step by step from top to next in chronological order, you can gradually understand the role each object plays in the pattern.
It is impossible to understand what is hidden in the diagram by glancing at the diagram, and the diagram must be deeply understood.
Think about the case yourself
Don't just read the cases in the book, but also try to think about some cases yourself.
In addition, we also need to think about whether the design patterns we have learned are applicable to the current scene when we design and program ourselves.
Understanding the roles – who plays Snow White
The design pattern is like a movie. There are various interactions between the "roles" of classes and interfaces, and a wonderful movie is performed together. In the movie, everyone has to act according to their role. The protagonist must act like the protagonist, and the enemy must act against the protagonist. The heroine will also appear, pushing the plot to a climax.
The same goes for design patterns. In each design pattern, classes and interfaces are arranged to play their respective roles. If each class and interface cannot understand the role it plays, it will not be able to deeply understand the overall plot of the movie, and it will not be able to play its own role well. This can lead to the hero subjugating, or the heroine becoming the villain; or turning a comedy into a tragedy, or a documentary into science fiction.
Next, we will learn a design pattern. At the same time, we also need to understand the roles that appear in design patterns. When reading the sample code, don't just stare at the code itself, but shift your focus to the role. When reading the code, think about what role each class and interface plays in the pattern.
If the schema is the same, they play the same role even if the class names are different. Recognizing the roles they play helps us understand patterns. In this way, even if the actors are changed, we can still understand the plot correctly.