Java Design Patterns 1: Introduction to Design Patterns
What are design patterns
A design pattern is a set of repeated, commonly known, categorized and catalogued summaries of code design experience. Design patterns are used to reusable code, make code easier to understand by others, and ensure code reliability. There is no doubt that design patterns are win-win for themselves, others and systems. Design patterns make code compilation truly engineering. Design patterns are the cornerstone of software engineering, just like the structure of a building.
In general, design patterns are divided into 3 categories and a total of 23 types:
1. Creation mode, a total of 5 types
Factory Method Pattern, Abstract Factory Pattern, Singleton Pattern, Builder Pattern, Prototype Pattern
2. Structural mode, a total of 7 types
Adapter Pattern, Decorator Pattern, Facade Pattern, Bridge Pattern, Composition Pattern, Flyweight Pattern
3. Behavioral mode, a total of 11 types
Strategy Pattern, Template Method Pattern, Observer Pattern, Iterator Pattern, Chain of Responsibility Pattern, Command Pattern, Memorandum Pattern, State Pattern, Visitor Pattern, Mediator Pattern, Interpreter Pattern
In fact, there are two types, namely concurrency mode and thread pool mode. The module of the design pattern will not explain every design pattern, but select some important and commonly used design patterns to explain, the quality is not the weight.
Six principles of design patterns
1. Open-Closed Principle OCP
The open-closed principle says that it is open for extension and closed for modification . When the program needs to be extended, the original code cannot be modified, which is also to make the program more scalable, easy to upgrade and maintain.
2. Liskov Substitution Principle LSP
In software, a base class object is replaced by its subclass object, and the program will not generate any errors and exceptions, and vice versa. If a software entity uses a subclass object, it must not be able to use the base class object. The program performance of the Liskov substitution principle is: try to use the base class type to define the object in the program, and then determine its subclass type at runtime, and replace the parent class with the subclass object.
3. Inversion of Control Principle IOC
Programming against interfaces, relying on abstractions rather than concrete
4. Interface isolation principle ISP
Using multiple isolated interfaces is better than using a single interface
5. Law of Demeter DP
An entity should interact with other entities as little as possible, so that the system functional modules are relatively independent
6. The principle of synthesis and reuse
Try to use composition/aggregation instead of inheritance
three keywords in design
1. Abstraction
Extracting common and essential features from many things and discarding non-essential features is abstraction. The process of abstraction is also a process of tailoring. When abstracting, it is different, depending on the angle of abstraction. The angle of abstraction depends on the purpose of analyzing the problem.
2. Realization
The concrete realization given by the abstract class is the 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 more important. Usually we always say that good code should be "high cohesion, low coupling", so what is coupling?
The so-called coupling is some kind of strong correlation between the behavior of two entities . And removing the strong association between them is decoupling. Decoupling refers to decoupling the coupling between abstraction and realization, or changing the strong association between them to a weak association.
The so-called strong association refers to an association that has been determined at compile time and cannot be dynamically changed at runtime ; the so-called weak association is an association that can be dynamically determined and dynamically changed at runtime . From this definition, the inheritance relationship is a strong relationship, and the aggregation relationship is a weak relationship.
MVC Design Pattern
The MVC design pattern is not one of the 23 design patterns. As for why, I will talk about it later, but because this is very common and important, I will talk about it.
The full name of MVC is Model View Controller, which is the abbreviation of Model-View-Controller, a software design paradigm. MVC organizes code with a method of separating business logic, data, and interface display, and aggregates business logic into one view. While improving and customizing the interface and user interaction, there is no need to rewrite business logic.
The MVC design pattern also provides full control over HTML, CSS, and JS. Let's take a look at several parts of the MVC design pattern:
1. Model Model
Models identify enterprise data and business rules, and among the three components of MVC, models have the most processing tasks. The data returned by the model is neutral, that is to say, the model has nothing to do with the data format. Such a model can provide data for multiple views. Since the code applied to the model only needs to be written once and can be reused by multiple views, it reduces the code duplication
2. View View
A view is the interface that the user sees and interacts with. For old-fashioned web applications, the view is the interface composed of HTML elements. In modern web applications, HTML still plays an important role in the view, but some new technologies have emerged one after another, including XHTML, XML/XSL , WML and other markup languages and Web Services.
The nice thing about MVC is that it can handle a lot of different views for the application, no real processing actually happens in the view, the view is just a way to output data and allow the user to manipulate it
3. Controller Controller
The controller accepts the user's input and invokes the model and view to fulfill the user's needs, so when the hyperlink in the stand-alone web page and the HTML form are sent, the controller itself does not output anything and do any processing, it just receives the request and decides Which model component is called to handle the request, and then which view is used to display the returned data
Using the MVC layered model helps manage complex applications because developers can focus on one aspect at a time. For example, developers can focus on view design without relying on business logic, while also making application testing easier.
Using the MVC layered model also simplifies group development, where different developers can develop views, controller logic, and business logic at the same time.
The most typical MVC is JSP+servlet+javabean .
Why the MVC design pattern is not one of the 23 design patterns
Look at this problem from two angles:
1. We call the MVC design pattern so, so is MVC a design pattern? Or is MVC a kind of framework? Frameworks and design patterns, while similar, are fundamentally different. A design pattern is a description of a recurring problem in a certain environment and a solution to the problem. It is more abstract than a framework; a framework can be expressed in code, and can be directly executed or reused, while design patterns are only instances. To be expressed in code, design patterns are smaller elements than frames. A framework often contains one or more design patterns. The framework is always aimed at a specific application area, but the same design pattern can be applied to various applications. It can be said that the framework is software, and the design pattern is the knowledge of the software; the framework is the great wisdom, which is used to divide the software design; the design pattern is a small skill, which proposes solutions to specific problems to improve the code reuse rate and reduce the coupling degree. . From this perspective, MVC should belong to a framework, not a design pattern
2. The first point said, "A framework often contains one or more design patterns", which is actually true. The authors of "GOF", that is, "Design Patterns", did not mention MVC as a design pattern. In their view, MVC is actually an evolution of the design patterns of the other three attractions: Observer Pattern + Strategy Pattern + Combination pattern, factory pattern and decorator pattern may also be used according to different implementations of MVC in the framework. For example, the model is the data of the application, and the view handles the content displayed to the user on the screen. To this end, MVC is based on the push/subscribe model on the core communication. When a model changes, it sends update notifications to other modules of the application. Subscribers- --- Usually a controller then updates the corresponding view. This natural observation relationship promotes multiple views to be associated with the same model.
===========================================================