IOS design patterns-(1) Overview
There have been a lot of free schedules recently. There is no good idea about iOS apps, so let's just put it down and stop writing it. Spend some time learning the design model.
A series of blog posts will be written to record the learning process of design patterns.
Of course, because I am engaged in iOS, I will design the code later and try to combine it with objective-c.
I. Definition
Design pattern is a set of summary of code Design experiences that are repeatedly used, known to most people, classified and catalogued.
The design pattern is used to make code reusable, make it easier for others to understand, and ensure code reliability.
Undoubtedly,
The design pattern is win-win for others and the system; the pattern enables code compilation to be truly engineered; The design pattern is the cornerstone of software engineering, just like the structure of a building.
II. Purpose
The purpose is to teach you how to organize code Templates using authentic and reliable designs. Simply put, it is a general and excellent experience summarized and abstracted by the predecessors in the Process of program design.
The main purpose is to increase Program Flexibility and reusability.
On the other hand, it also helps standardize program design and improve system development progress.
Some people also advise: do not pay too much attention to the "Design Model" of the program ". Sometimes it is easier to write a simple algorithm than to introduce a certain mode. In most cases, the program code should be easy to understand, and even the cleaners can understand it. However, in large projects or frameworks, there is no design pattern to organize code, which is hard to understand.
A software design model is just a guide. It must be specifically designed based on the programming language and the characteristics and requirements of your application.
3. Principles
There are several object-oriented principles:
Liskov Substitution Principle (LSP) depends on the Dependency Inversion Principle (DIP) Interface isolation Principle (ISP) principle of minimum Knowledge (Principle of Least Knowledge and PLK)
The principle of openness and closure is idealistic and is the ultimate goal of object-oriented design. The other several items can be seen as the implementation method of the open and closed principle.
The design pattern is to achieve these principles, so as to achieve code reuse and increase maintainability.
1) Open-ClosedPrinciple (OCP): Open to extension and close to Modification
It means that in a system, the extension is open and the modification is closed. A good system can extend your function without modifying the source code .. the key to achieving the principle of openness and closure is abstraction.
By extending existing software systems, new behaviors can be provided to meet new requirements for the software, so that the software in change has certain adaptability and flexibility. Existing software modules, especially the most important abstract layer modules, cannot be modified, which makes the software system in change stable and continuous.
In the open-closed principle, abstract classes or interfaces cannot be modified, and specific implementation classes are allowed to be extended, abstract classes and interfaces play an extremely important role in the open-closed principle .. that is, to predict the potential changing needs. we also anticipate all possible known extensions .. so here abstraction is the key !!!
Closed principle of variability: Find the variable factors of the system and encapsulate it .. this is the best implementation of the open-close principle .. do not place your variable factors in multiple classes, or scatter them in every corner of the program .. you should encapsulate variable factors .. do not enclose variable factors .. the best solution is to block your variable factors !! Avoid the appearance of ultra-large, ultra-long, and ultra-long methods !! Adding an artistic atmosphere to your program and making the program artistic is our goal !!
2) rieshield replacement principle: any base class can appear, and sub-classes can also appear.
Liskov Substitution Principle (Rishi replacement Principle): The subclass must be able to replace the base class from where it appears. Subclass can also add behavior based on the base class. This yi refers to the relationship between the base class and the sub-class. Only when such a relationship exists will the Li's replacement principle exist. Square is a rectangle, a classic example of how to understand the Li's replacement principle.
3) Dependency inversion principle: dependency abstraction instead of specific implementation.
Dependence Inversion Principle: It depends on abstraction and not on specifics. In short, the dependency inversion principle requires the client to rely on abstract coupling. Principles:
(1) Abstraction should not depend on details; details should depend on abstraction;
(2) programming for interfaces rather than implementation.
If the principle of open and closed is the goal, the principle of dependency reversal is the means to reach the principle of open and closed .. if we want to achieve the best principle of open and closed, we should try to abide by the principle of dependency reversal .. it can be said that the dependency reversal principle is the best specification for abstraction !! In my personal sense, the dependency reversal principle is also a supplement to the lee's replacement principle. You have understood the Lee's replacement principle, and it is easy to understand the dependency reversal principle ..
4) synthesis/aggregation Reuse Principle (CARP): Use the synthesis/aggregation principle as much as possible, rather than the inheritance relationship for software reuse.
The Composite/Aggregate ReusePrinciple or CARP principle is often referred to as the Composite ReusePrinciple or CRP principle. It uses some existing objects in a new object, make it a part of the new object. New objects reuse existing functions by delegating these objects. In short, we should try to use synthesis/aggregation instead of inheritance.
We should try to use the synthesis/aggregation principle instead of the inheritance relationship to achieve the purpose of software reuse. This principle is complementary to the lee's replacement principle, both of which are specific specifications for implementing the open-closed principle .. in violation of this principle: the open-closed principle cannot be implemented .. let's first look at what is synthesis and what is aggregation.
What is synthesis?
Synthesis: refers to the relationship between a person and his/her relying on him. For example, a person cannot share his/her house and furniture, because they all belong to him .. and if there are no people, the relationship will be gone .. in this example, Wuji Baifeng pills are synthesized from Wuji and superior medicinal herbs .. like weapon and equipment merging in online games, a variety of things are combined into a super powerful things ..
What is aggregation?
Aggregation: aggregation is a stronger dependency than the compositing relationship. Aggregation is an integral part of the individual. For example, a Mercedes-Benz S360 car is used for the S360 engine, the relationship between the Benz S360 tires .. these relationships are of an aggregation nature .. because of the S360 engine and S360 tires, they can only be used by the S360 car. After leaving the S360 car, they lose their meaning .. in our design, such a relationship should not appear frequently .. this will increase the Coupling Degree of the design ..
Understand the relationship between synthesis and aggregation, and then understand the principles of synthesis/aggregation .. it should be avoided in system design that the hierarchy of a class should be more than three times .. if so, you can consider restructuring your code or re-designing the structure .. of course, the best way is to consider using the synthesis/aggregation principle...
5) dimit law: classes in the system should not interact with other classes as much as possible to reduce the coupling between classes.
The Law of Demeter (or the short-cut level of measure) is also called the Least Knowledge Principle (Least Knowledge Principle or LKP). That is to say, an object should have as little Knowledge as possible about other objects.
Other statement: only communicate with your friends directly. Do not talk to strangers. A class should know the least about the classes that need to be coupled or called. It doesn't matter to me how complicated your (the class to be coupled or called) is. That's your business, I will know the public method you provided, so I will call so much, and nothing else cares.
Dumit's law and design pattern Facade Pattern and Mediator Pattern make people ignorant
Classes in the system should try not to interact with other classes to reduce the coupling between classes, because in your system, you may need to modify these classes during expansion, the relationship between classes determines the complexity of modifications. The more interactions there are, the more difficult the modifications will be. Otherwise, the smaller the interactions, the smaller the difficulty of modification .. for example, if Class A depends on Class B, Class B depends on Class C. When you modify Class A, you need to consider whether Class B will be affected, does the impact of Class B affect class C .. if Class C is dependent on Class D at this time, I think this change will be affected ..
6) interface isolation rule: This rule is consistent with the dimit rule.
Interface Segregation Principle: it is better to use multiple special interfaces than to use a single total Interface. In other words, from the perspective of a customer class: the dependence of a class on another class should be based on the minimum interface.
An interface that is too bloated is a pollution to the interface. Customers should not be forced to rely on methods they do not need.
The dimit rule is the purpose, and the interface isolation rule is the specification of the dimit rule .. in order to achieve as little coupling as possible, we need to use interfaces to define classes and use interfaces to constrain classes. to meet the requirements of the dimit rule, it is best to implement the interface isolation rule and implement the interface isolation rule, so that you can satisfy the dimit rule...
4. Category
There are 23 Design Patterns in total.
Creation Mode: Singleton mode, abstract factory mode, builder mode, factory mode, and prototype mode. Structural mode: adapter mode, bridging mode, decoration mode, combination mode, appearance mode, metadata mode, and proxy mode. Behavior mode: template Method mode, command mode, iterator mode, observer mode, intermediary mode, memorandum mode, interpreter mode, state mode, policy mode, responsibility chain mode, and visitor mode. The following is an introduction to lexicographic sorting.
Abstract Factory (Abstract Factory mode): provides an interface for creating a series of related or mutually dependent objects without specifying their specific classes. Adapter mode: converts an interface of a class to another interface that the customer wants. The Adapter mode allows the classes that cannot work together due to incompatibility of interfaces to work together. Bridge: separates abstract parts from their implementations so that they can all change independently. Builder mode: separates the construction of a complex object from its representation, so that different representations can be created during the same construction process. Chain of Responsibility (Responsibility Chain mode): to cancel the coupling between the request sender and receiver, multiple objects have the opportunity to process the request. Connect these objects into a chain and pass the request along the chain until an object processes it. Command (Command mode): encapsulate a request as an object, so that you can parameterize the customer with different requests; queue requests or record request logs, and supports cancelable operations. Composite (combination mode): combines objects into a tree structure to represent a "part-whole" hierarchy. It makes the customer's use of a single object and composite object consistent. Decorator: dynamically adds some additional responsibilities to an object. The extended function is more flexible than the subclass generation method. Facade (appearance mode): provides a consistent interface for a group of interfaces in the subsystem. The Facade mode defines a high-level interface, which makes the subsystem easier to use. Factory Method (Factory mode): defines an interface for creating objects, so that the subclass determines which class to instantiate. Factory Method delays the instantiation of a class to its subclass. Flyweight: uses the sharing technology to effectively support a large number of fine-grained objects. Interpreter (parser mode): defines a language, a syntax expression, and an Interpreter that uses this representation to explain sentences in a language. Iterator (Iterator mode): provides a method to access each element in an aggregate object sequentially without exposing the internal representation of the object. Mediator: A Mediator object is used to encapsulate a series of object interactions. The intermediary makes the objects do not need to be explicitly referenced to each other, so that the coupling is loose and the interaction between them can be changed independently. Memento: captures the internal state of an object without compromising encapsulation, and saves the State outside the object. In this way, the object can be restored to the Saved state. Observer (Observer mode): defines a one-to-many dependency between objects, so that when the state of an object changes, all objects dependent on it are notified and automatically refreshed. Prototype: Use a Prototype instance to specify the type of the object to be created, and copy the Prototype to create a new object. Proxy: provides a Proxy for other objects to control access to this object. Singleton (Singleton mode): ensures that a class has only one instance and provides a global access point to it. The Singleton mode is one of the simplest design patterns, but it has many defects for Java developers. In his column in September, David Geary discussed the singleton mode, multi-threading, class loaders, and serialization) how to handle these defects. State: allows an object to change its behavior when its internal State changes. The object seems to have modified its class. Strategy: defines a series of algorithms, encapsulates them one by one, and makes them replaceable. This mode makes the algorithm changes independent of the customers who use it. Template Method: defines the skeleton of an algorithm in an operation, and delays some steps to the subclass. The Template Method allows the subclass to redefine certain steps of an algorithm without changing the structure of an algorithm. Visitor (Visitor mode): an operation that acts on each element in an object structure. It allows you to define new operations that act on these elements without changing the classes of each element.
Although this article looks big, it's all text. However, it is indeed something you need to know about the learning design model.
Of course, my documents here are also copied from the Internet. I have extracted some information that I think is necessary to understand.
You can understand this knowledge.
On the way to learning, I will share with you
