Recently free to arrange more time, iOS applications, there is no good idea, first put down, do not write. Take time to learn design patterns.
You will then write a series of blog posts documenting the design pattern learning process.
Of course, because I am engaged in iOS, so after the design code part, will try to combine with objective-c.
iOS design mode-Overview by Colin,
Reprint Please specify source: http://blog.csdn.net/hitwhylz/article/details/40372113
One. Defined
Design patterns are a set of reusable, most known, categorized purposes, code design experience Summary.
Design patterns are used in order to reuse code, make code easier for others to understand, and ensure code reliability.
No doubt
- Design patterns in others in the system are multi-win;
- Model to make code compilation truly engineering;
- The design pattern is the cornerstone of software engineering, just like the structure of a building.
Two. Objective
The goal is to teach you how to use real and reliable design to organize your code templates. Simply put, it is from the predecessors in the process of design summary, abstraction of the general good experience.
The main objective is to increase the flexibility and reusability of the program .
On the other hand, it also helps to standardize the programming and improve the system development progress .
There is also some advice: do not focus too much on the "design Patterns" of the program. Sometimes it's easier to write a simple algorithm than to introduce a pattern. In most cases, the code should be easy to understand and even cleaner to read. However, in large projects or frameworks, there is no design pattern to organize the code, others are not easy to understand.
A software design model is just a guide. It must be designed according to the programming language and the characteristics and requirements of your application.
Three. Principle
There are several principles for object orientation:
- Opening and closing principle (Open Closed PRINCIPLE,OCP)
- The principle of substitution on the Richter scale (Liskov Substitution PRINCIPLE,LSP)
- Dependency reversal principle (Dependency inversion Principle,dip)
- Interface Isolation principle (Interface segregation principle,isp)
- Synthesis/Aggregation multiplexing principles (composite/aggregate reuse Principle,carp)
- Minimum knowledge principle (Principle of Least Knowledge,plk, also called Dimitri Law)
The opening and closing principle has the idealistic color, it is the object-oriented design ultimate goal. The other several, can be regarded as the opening and closing principle of the implementation method.
The design pattern is the realization of these principles, so as to achieve code reuse, increase maintainability.
1) "Open-close" principle (open-closedprinciple Abbreviation: OCP): Open for expansion, close for modification
Meaning, in a system, for the extension is open, for the modification is closed, a good system is not to modify the source code in the case, you can expand your functionality. The key to realizing the opening and closing principle is abstraction.
By extending the existing software system, new behaviors can be provided to meet the new requirements of the software, so that the software in change has some adaptability and flexibility. Existing software modules, especially the most important abstraction layer module can not be modified, which makes the software system in the change has some stability and continuity.
In the "open-closed" principle, it is not allowed to modify an abstract class or interface, allowing the extension of a specific implementation class, abstract classes and interfaces play an extremely important role in the "open-close" principle. The need to anticipate possible changes. And anticipate all the extensions that might be known. So "abstraction" here is the key!!!
The closed principle of variability: Find the variable factor of the system and encapsulate it. This is the best implementation of the "open-close" principle. Do not put your variables in multiple classes, or scattered around the program's various corners. You should put the variable factor in the envelope up. and avoid the use of variable factors in the envelope together. The best solution is to block envelopes for your variable factor!! Avoid super large class, Super long class, the appearance of super long Method!! To your program to increase the artistic flavor, the process of art is our goal!!
2) The principle of substitution of the Richter scale: where any base class can occur, subclasses can also appear
Liskov Substitution Principle (Richter substitution principle): Subclasses can have to be able to replace the base class from where it appears. Subclasses can also add behavior based on the base class. This yi is about the relationship between the base class and the subclass, and only when the relationship exists does the Richter substitution principle exist. A square is a classic example of how to understand the principle of substitution on the Richter scale.
3) Dependency reversal principle:: Rely on abstraction instead of relying on specific implementations.
The principle of dependency inversion (dependence inversion Principle) is to rely on abstraction, not on specifics. Simply put, the dependency inversion principle requires the client to rely on abstract coupling. Principle statement:
(1) Abstraction should not be dependent on detail; details should be dependent on abstraction;
(2) to program for the interface, do not program for implementation.
If the principle of opening is the goal, reliance on the reversal principle is the means to reach the "open and close" principle. If you want to achieve the best "open and close" principle, we should try to comply with the principle of dependency reversal. It can be said that reliance on the reverse principle is the "abstraction" of the best specification!! I personally feel that reliance on the reversal principle is also a supplement to the Richter substitution principle. You understand the principle of the Richter substitution, and it should be easy to understand the dependency reversal principle.
4) Synthesis/aggregation multiplexing principle (CARP): To maximize the use of the composition/aggregation principle, rather than the inheritance relationship to achieve the purpose of software reuse
The synthesis/aggregation multiplexing principle (composite/aggregate reuseprinciple or carp) is often called the synthetic multiplexing principle (Composite reuseprinciple or CRP), which is to use some existing objects in a new object , making it part of the new object, and the new object is being reused for the purpose of the existing functionality by delegating to those objects. In short, use composition/aggregation as much as possible, and do not use inheritance as much as possible.
Use the composition/aggregation principle as much as possible, rather than inheriting relationships to achieve software reuse. This principle and the Richter substitution principle complement each other, both are concrete implementation of the "open-closed" principle of the norms. Violation of this principle: "open-closed" principle can not be achieved. Let's take a look at what is synthesis and what is aggregation.
What is synthesis?
Synthesis: Refers to the relationship that a whole has to rely on him, for example: a person to his house and furniture, wherein his house and furniture can not be shared, because those things are his own. And the man is gone, and this relationship is gone. This example is like, black chicken hundred chicken pill This product, it is has the black chicken and the fine medicinal herbs synthesis comes the same. Also like the weapons and equipment in the online game synthesis, a variety of things combined into a very strong thing like.
What is aggregation?
Aggregation: Aggregation is a stronger dependency than a synthetic relationship, and aggregation is an integral part of the individual, for example, a Mercedes-Benz S360 car, the relationship between Mercedes-Benz S360 engine, Mercedes-Benz S360 tires. These relationships are aggregated in nature. Because Mercedes-Benz S360 engine and Mercedes-Benz S360 tires They can only be used by Mercedes-Benz S360 cars, leaving the Mercedes-Benz S360 car, they lost the meaning of existence. In our design, such a relationship should not occur frequently. This will increase the coupling of the design.
Understanding the synthesis and aggregation relationships, and then to understand the composition/aggregation principles should be clear. To avoid appearing in system design, a class inherits more than 3 times. If so, consider refactoring your code, or redesign the structure. Of course, the best way is to consider the use of synthetic/aggregation principles ...
5) Dimitri rule: Class in the system, try not to interact with other classes, reduce the coupling between classes
The Dimitri rule (law of Demeter or abbreviated LOD) is also called the least knowledge principle (Least knowledge principle or abbreviated to LKP), that is, one object should have as little understanding of other objects as possible.
Other statements: only communicate with your direct friends and don't talk to strangers. A class should know the least about the classes that it needs to be coupled or called, and how complex the internals of your (coupled or called classes) are to me, that's your business, I know the public method you provide, and I'm calling so much that the rest doesn't care.
Dimitri Law and design pattern facade mode, mediator mode make people ignorant
The class in the system, try not to interact with other classes, reduce the coupling between classes, because in your system, you may need to modify these classes, and the relationship between classes and class determines the complexity of the modification, the more interaction, the more difficult to modify, conversely, if the interaction of the smaller, The less difficult it is to modify. For example, Class A relies on Class B, then Class B relies on Class C, and when you modify Class A, you have to consider whether Class B will be affected, and whether the effect of Class B will affect the Class C. If at this time class C again depends on class D, hehe, I think such changes have been affected.
6) Interface Isolation Law: This law is connected to the Dimitri law.
The interface isolation principle (Interface segregation Principle) is that it is better to use multiple specialized interfaces than to use a single total interface. In other words, from the perspective of a customer class, the dependency of one class on another class should be based on the smallest interface.
An overly bloated interface is a pollution to the interface. Customers should not be forced to rely on methods that they do not use.
The Dimitri Law is the purpose, and the interface isolation law is the norm of the Dimitri Law. In order to be as small as possible, we need to use interfaces to standardize classes, and interfaces to constrain classes. To achieve the requirements of Dimitri Law, it is best to implement the interface isolation law, the implementation of interface isolation law, you also meet the Dimitri law ...
Four. Classification
The design pattern is divided into three types, a total of 23 kinds.
- Create pattern: Singleton mode, abstract Factory mode, builder mode, Factory mode, prototype mode.
- Structural mode: Adapter mode, bridge mode, decoration mode, combination mode, appearance mode, enjoy meta mode, proxy mode.
- Behavioral Patterns: Template method mode, command mode, iterator mode, observer pattern, Mediator mode, Memo mode, interpreter mode, state mode, policy mode, responsibility chain mode, visitor pattern.
The following is an introduction to dictionary ordering.
- Abstract Factory: Provides an interface to create a series of related or interdependent objects without specifying their specific classes.
- Adapter (Adapter mode): Transforms the interface of one class into another interface that the customer wants. The adapter mode makes it possible for those classes that would otherwise not work together because of incompatible interfaces to work together.
- Bridge (Bridging Mode): separates the abstract part from its implementation, so that they can all change independently.
- Builder (Builder mode): separates the construction of a complex object from its representation so that the same build process can create different representations.
- Chain of Responsibility (responsibility chain Mode): to decouple the sender and receiver of the request, so that multiple objects have an opportunity to process the request. Link the objects together and pass the request along the chain until an object handles it.
- Command mode: Encapsulates a request as an object so that you can parameterize the customer with different requests, queue requests or log requests, and support actions that can be canceled.
- Composite (combined mode): combines objects into a tree structure to represent a "partial-whole" hierarchy. It enables customers to have consistent use of individual objects and composite objects.
- Decorator (Decorative mode): Dynamically add some additional responsibilities to an object. In terms of extension functionality, it is more flexible than generating subclasses.
- Facade (appearance mode): Provides a consistent interface for a set of interfaces in a subsystem, and the facade schema defines a high-level interface that makes this subsystem easier to use.
- Factory Method (Factory mode): Defines an interface for creating objects, letting subclasses decide which class to instantiate. The Factory method defers the instantiation of a class to its subclasses.
- Flyweight (enjoy meta mode): Use sharing technology to effectively support a large number of fine-grained objects.
- Interpreter (parser mode): Given a language, defines a representation of its grammar and defines an interpreter that uses that representation to interpret sentences in the language.
- Iterator (iterator mode): Provides a way to sequentially access individual elements of an aggregated object without exposing the object's internal representation.
- Mediator (mediation mode): Uses a Mediation object to encapsulate a series of object interactions. The mediator makes the objects not need to explicitly reference each other, so that they are loosely coupled, and can independently change the interaction between them.
- Memento (Memo mode): captures the internal state of an object without compromising encapsulation, and saves the state outside that object. The object can then 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 that depend on it are notified and refreshed automatically.
- Prototype (prototype mode): Specifies the kind of object created with the prototype instance, and creates a new object by copying the prototype.
- Proxy mode: Provides a proxy for other objects to control access to this object.
- Singleton (singleton mode): guarantees that a class has only one instance and provides a global access point to access it. Singleton mode is one of the simplest design patterns, but it has many drawbacks for Java developers. In the September column, David Geary explored the singleton pattern and how to deal with these flaws in the face of Multithreading (multi-threading), class loaders (Classes Loaders), and serialization (serialization).
- State mode: Allows an object to change its behavior when its internal state changes. The object appears to have modified the class it belongs to.
- Strategy (Policy mode): Defines a series of algorithms, encapsulates them one by one, and allows them to be replaced by each other. This mode allows the algorithm to be changed independently of the customer using it.
- Template Method Mode: Defines the skeleton of an algorithm in an operation, and delays some steps into subclasses. The Template method allows subclasses to redefine some specific steps of the algorithm without altering the structure of an algorithm.
- Visitor (Visitor mode): represents an operation that acts on elements in an object's structure. It allows you to define new actions that act on these elements without changing the class of each element.
Although this article looks relatively big, it is all text. But it's really something to learn about design patterns.
Of course, the information I have here is also copy from the Internet. Excerpts of some of the things I feel necessary to understand.
For this knowledge, it is better to look at the understanding.
Study on the road, with June encouragement
iOS design mode-Overview
