The implementation example of the strategy mode in the development of IOS app design mode _ios

This is an introduction to the Strategy Model (strategy pattern), which is a relatively simple pattern. It is also called the policy model (Policy pattern). The strategy pattern uses the object-oriented inheritance and polymorphism mechanism, and nothing else. The policy model is suitable for use in: 1. Multiple classes have only a slightly different scenario on the algorithm or behavior. 2. The algorithm needs to be free to switch scenes. 3. Need to screen algorithm rules of the scene. There is certainly a need to be aware of the use of policy patterns, not too many policy classes, and if a policy family has more than 4 specific policies, consider blending mode to address policy class bloat and external exposure issues. In the actual project, we generally implement the policy class declaration through the factory method pattern.

Here we will explain the policy model in detail.

Policy Mode definition:

Define a family of algorithms, encapsulate each one, and make them interchangeable. (defines a set of algorithms that encapsulate each algorithm and are interchangeable between them.) )

Below I show the class hierarchy diagram of the policy pattern as follows:

As shown in the figure, the strategy class hierarchy defines a series of reusable algorithms and behaviors for the context, and inheritance helps to extract the public functions of these algorithms. Below I use an ordinary supermarket charge example simple simulation this pattern. I'll introduce the corresponding classes:

Context class ——————————— Cashcontext class
Strategy Class ——————————— –cashsuper class
Concretestrategya class —————-Cashnormal class
Concretestrategyb class —————-Cashrebate class
CONCRETESTRATEGYC class —————-Cashreturn class
OK, above is the objective C source code class that will be shown to you.

Below, I will show the corresponding classes above for your reference:

Note: All of the code in this article is compiled in an arc environment.

Cashcontext class Interface

Copy Code code as follows:

#import <Foundation/Foundation.h>
#import "CashSuper.h"

@interface cashcontext:nsobject{
@private Cashsuper *cs;
}
-(cashcontext*) Myinit: (int) Types;
-(void) Setcashsuper: (cashsuper*) Cashsuper;
-(double) GetResult: (double) money;
@end

Cashcontext class implementation

Copy Code code as follows:

#import "CashContext.h"
#import "CashNormal.h"
#import "CashRebate.h"
#import "CashReturn.h"

@implementation Cashcontext

-(cashcontext*) Myinit: (int) types{
int mytypes;
Mytypes = Types;
Switch (mytypes) {
Case 1:
[Self setcashsuper:[[cashnormalalloc]init]];
Break
Case 2:
[Self setcashsuper:[[cashreturnalloc]myinit:300 and:100]];
Break
Case 3:
[Self setcashsuper:[[cashrebatealloc]myinit:0.8]];
Break
Default
Break
}
return self;
}
-(void) Setcashsuper: (cashsuper*) cashsuper{
CS = Cashsuper;
}
-(double) GetResult: (double) money{
return [CS Acceptcash:money];
}

@end

Cashsuper class Interface

Copy Code code as follows:

#import <Foundation/Foundation.h>

@interface Cashsuper:nsobject
-(double) Acceptcash: (double) money;
@end

Cashsuper class implementation

Copy Code code as follows:

#import "CashSuper.h"

@implementation Cashsuper

-(double) Acceptcash: (double) money{
return-1.0; Returning here-1.0 does not make any sense, just to define this method
}

@end

Cashnormal class Interface

Copy Code code as follows:

#import "CashSuper.h"

@interface Cashnormal:cashsuper
@end

Cashnormal class implementation

Copy Code code as follows:

#import "CashNormal.h"

-(double) Acceptcash: (double) money{
return money;
}

@end

Cashrebate class Interface

Copy Code code as follows:

#import "CashSuper.h"

@interface cashrebate:cashsuper{
@private double moneyrebate;
}
@property double moneyrebate;
-(cashrebate*) Myinit: (double) moneyrebates;
@end

Cashrebate implementation

Copy Code code as follows:

#import "CashRebate.h"

@implementation Cashrebate
@synthesize moneyrebate;

-(cashrebate*) Myinit: (double) moneyrebates{
[Self setmoneyrebate:moneyrebates];
return self;
}
-(double) Acceptcash: (double) money{
return Moneyrebate*money;
}

@end

Cashreturn class Interface

Copy Code code as follows:

#import "CashSuper.h"

@interface cashreturn:cashsuper{
@private double moneycondition;
@private double Moneyreturn;
}
@property double moneycondition;
@property double Moneyreturn;
-(cashreturn*) Myinit: (Double) moneyconditions and: (double) moneyreturns;
@end

Cashreturn class implementation

Copy Code code as follows:

#import "CashReturn.h"

@implementation Cashreturn
@synthesize Moneyreturn;
@synthesize moneycondition;

-(cashreturn*) Myinit: (Double) moneyconditions  and: (double) moneyreturns{
    [self Setmoneyreturn:moneyreturns];
    [self setmoneycondition:moneyconditions];
    return self;
}
-(double) Acceptcash: (double) money{
    double result;
    result = Money
    @try {
        if (Money >=moneycondition) {
            result = money-(money/moneycondition) * Moneyreturn;
       }
   }
    @catch (nsexception *exception) {
        NSLog (@) oh! man!! Cashreturn has something wrong! ");
   }
    @finally {
        return result;
    }
}

@end

Main method call

Copy Code code as follows:

#import <Foundation/Foundation.h>
#import "CashContext.h"

int main (int argc, const char *argv[])
{
@autoreleasepool {
Cashcontext *CC = [[Cashcontext alloc]myinit:3];
Double total;
Total = [CC getresult:400];
NSLog (@ "Total money 400,the resual be%f", total);
}
return 0;
}

These are the corresponding classes in the corresponding policy pattern, and one thing to declare is that the code is written in an arc environment, so there is no need to manually release the resources. So some pass-pointer places are not manually released, explain here.

Under what circumstances it is necessary to use a policy pattern, but my understanding is that when we analyze requirements, we need to apply different business rules at different times to consider the possibility of using a policy pattern to handle this change. In addition, the advantage of the policy model is that it simplifies unit testing because each algorithm has its own class that can be tested individually through its own interface.