iOS design mode-(4) Policy mode

Theory section, reference blog: http://blog.csdn.net/hguisu/article/details/7558249

1. Overview

In software development also often encounter similar situation, to achieve a certain function has a number of algorithms or strategies, we can choose different algorithms or strategies according to the environment or conditions to complete the function . such as finding, sorting, and so on, a commonly used method is hard-coded (Coding) in a class, if you need to provide a variety of search algorithms, you can write these algorithms into a class, in the class to provide multiple methods, each method corresponding to a specific search algorithm ; Of course, these lookup algorithms can be encapsulated in a unified approach, through the if...else ... or case and other conditional judgment statements to make the selection. Both of these implementations can be called hard-coded, and if a new lookup algorithm needs to be added, the source code of the encapsulated algorithm class needs to be modified, and the client calling code needs to be changed. In this algorithm class to encapsulate a large number of search algorithms, the class code will be more complex, maintenance is more difficult. This is even more undesirable if we include these policies on the client , which will cause the client program to be large and difficult to maintain, and the problem will become more serious if there are a large number of algorithms to choose from.

Example 1: A menu function can determine whether to use a horizontal or vertical arrangement based on the user's "skin" preferences. Colleagues can flexibly increase the display style of the menu.

Example 2: Travel: We can have several strategies to consider: Can ride bicycles, cars, do trains, airplanes. Each policy can get the same results, but they use different resources. The choice of strategy is based on cost, time, and the ease of use of the tool in each of these ways.

2. Questions

How do you separate the algorithm from the object so that the algorithm can change independently of the customers who use it?

3. Solution

strategy mode: A series of algorithms are defined to encapsulate each algorithm and make them interchangeable with each other. This mode allows the algorithm to be independent of the customers who use it. also known as policy mode. (Definea family of Algorithms,encapsulate each one, andmake them interchangeable. Strategy lets the algorithmvary independently from clients. )

The policy pattern distinguishes between the object itself and the arithmetic rules, which The function is very powerful, because the core idea of the design pattern itself is the idea of the polymorphism of object-oriented programming.

4. Applicability

use Strategy mode when the following conditions are present
1)? Many of the related classes are just different in behavior. Policy provides a way to configure a class with one behavior in multiple behaviors. That is, a system needs to dynamically select one of several algorithms.
2)? You need to use different variants of an algorithm. For example, you might define algorithms that reflect different spatial/temporal tradeoffs. When these variants are implemented as a class hierarchy of an algorithm, the policy mode can be used.
3) The algorithm uses data that the customer should not know about. You can use the policy mode to avoid exposing complex, algorithmic-related data structures.
4)? A class defines a variety of behaviors, and these behaviors appear as multiple conditional statements in the operation of this class. The related conditional branches are moved into their respective strategy classes in place of these conditional statements.

5. Structure

6. Effects

strategy mode has some of the following advantages:
2) provides a way to replace an inheritance relationship : inheritance provides another way to support multiple algorithms or behaviors. You can generate a subclass of a context class directly, giving it different behavior. But this will make the behavior hard line into the context, and the implementation of the algorithm and the implementation of the context to mix, so that the context is difficult to understand, difficult to maintain and difficult to expand, and can not dynamically change the algorithm. Finally you get a bunch of related classes, the only difference between them is the algorithm or behavior they use.   encapsulates the algorithm in a separate strategy class so that you can change it independently of its context, making it easy to switch, easy to understand, and easy to extend.
4) Implementation of the selection  strategy mode can provide different implementations of the same behavior. Customers can choose from different strategies based on different time/space tradeoffs.

strategy Mode disadvantage :

1) The client must know all the policy classes and decide for itself which policy class to use : This model has a potential disadvantage, that is, a customer to choose a suitable strategy must know how these strategy are different. You may have to expose your customers to specific implementation issues at this point. Therefore, you need to use Strategy mode only when these different behavior variants are related to customer behavior.
2) communication overhead between strategy and context : Regardless of whether the algorithms implemented by each concretestrategy are simple or complex, they share strategy defined interfaces. Therefore, it is possible that some concretestrategy will not use all of the information passed to them through this interface; simple concretestrategy may not be using any of them! This means that sometimes the context creates and initializes some parameters that will never be used. If there is such a problem, there will need to be more tightly coupled between the strategy and the context.
3) Policy mode will result in many policy classes : You can reduce the number of objects to some extent by using the enjoy meta mode. Increase the number of objects strategy increases the number of objects in an app. Sometimes you can reduce this overhead by implementing strategy as a stateless object that can be shared by each context. Any remaining state is maintained by the context. The context passes this state over every request to the Strategy object. Shared strategy should not maintain state between invocations.

7. iOS app Analytics

For example, when validating a user-entered form, we include validation of the telephone input box and verification of the message input box, which is different from the verification algorithm, and if the algorithm is considered a function, he has almost identical input parameters and return parameters. We can abstract this same function as a method of the base class (Inputvalidator) (bool ValidateInput (INPUT,ERROR)), and then abstract out two specific policy classes: Phone authentication class (Phonevalidator) and message validation classes (emailvalidator), they need to replicate the validation methods of the parent class in their implementations. In order to be able to invoke the validation method of the validation class normally, we need to customize a Uitextfield subclass Customtextfield, which has a Inputvalidator type reference and a validate method, This method calls Inputvalidator's validation method, and then calls the Customtextfield Validate method inside the Textfielddidendediting proxy method, so that we don't have to judge if the input is valid by the IF Else to handle each logic, and it's easier to scale up and improve reusability.

Example: Sorting algorithm, Nsarray sortedarrayusingselector; classic Duck will call, can fly case.

8. ios instance download

Here is an iOS version of the Duck project, which can be referenced under

Design mode-policy mode. zip

iOS design mode-(4) Policy mode