Design Mode-policy Mode

Policy mode: the number of IF-else policies you have, and the number of policy modes you can write.

The rule mode is also a mode that I have used in almost every corner. Because it can be said that he gave the most common if-Else To "Object-Oriented" and encapsulated the algorithm. In other words, when you have an IF-else code block, theoretically, it can all be changed to a policy mode. Of course, this is just an exaggerated example, the disadvantage of the design pattern lies in the relatively complicated code structure, and the idea structure is non-procedural. Therefore, it is only worthwhile to use the policy pattern for the IF-else block to be optimized.

[Business scenario ]-----------

There is a management system on hand, which has three permissions: ABC. After a logs on, the employee information is displayed. After B logs on, the inventory information is displayed. After C logs on, displays financial information. Currently, the system has only three identities. More identities will be entered at the same entry point in the future.

 

I [analysis stage ]-----------

A is like this, B is like this, C is like this .. if you want to determine if-Else In the login business at the first time, congratulations! It's very close to the policy mode! What's wrong? That's easy! I put the code first.

What would happen if-Else?

/*** Log on to the business logic processing class. Here, the struts2 idea is used as an example. * This loginservice is equivalent to calling loginaction, therefore, the method * @ Param user * @ return */Public String getpagebyidentity (User user) {// some other operations, such as dosomething (); // obtain the corresponding response page if (user. getidentity () = 1) {// read the database and other operations, prepare the Personnel Department data preparedataforhr (); // the personnel department's unique business processing hrotherservice (); // return to the success page return "HR";} else if (user. getidentity () = 2) {// read database and other operations, prepare Sales Department data preparedataforsale (); // sale department's unique business processing saleotherservice (); // return the success page return "sale";} else if (user. getidentity () = 3) {// read database and other operations, prepare financial department data preparedataforfinace (); // financial department's unique business processing finaceotherservice (); // return to the success page: Return "Finace";} else {return "error ";}}}

This idea is okay, but it is obvious that the code is redundant. Once new permissions are extended or the existing business is complicated, the code will be changed repeatedly. Therefore, use the policy mode:

II [design phase ]-------------------

Public class loginservice {Public String getpagebyidentity (User user) {// some other operations dosomething (); // here we start to delegate the IF-else logic judgment to the executor return loadstrategyexcutor.exe cute (User);} in the Policy mode );}}

/*** Policy execution class. The identity used is determined here and then mapped to different modes */public class loadstrategyexcutor {public static string execute (User user) {identityloadservice loadstrategy = NULL; Switch (user. getidentitycode () {Case 1: loadstrategy = new useraloadservice (); break; Case 2: loadstrategy = new userbloadservice (); break; Case 3: loadstrategy = new usercloadservice (); break; default: break;} return loadstrategy. doservice ();}}

Public class useraloadservice implements identityloadservice {@ override Public String doservice () {// read database and other operations, prepare Personnel Department data preparedataforhr (); // hrotherservice () exclusive to the Personnel Department; // return "HR";} public class userbloadservice implements identityloadservice {@ override Public String doservice () {// read the database and other operations, prepare the Sales Department data preparedataforsale (); // The business processing saleotherservice () exclusive to the sales department (); // return to the success page return "sale";} public class usercloadservice implements identityloadservice {@ override Public String doservice () {// read the database and other operations, prepare the Financial Department data preparedataforfinace (); // The finaceotherservice () exclusive to the financial department; // return to the success page return "Finace ";}}

III [verification phase ]--------------------

This analysis is clear:

1. The division of code responsibilities is clear. Different business changes modify different Java classes to facilitate development and management;
2. To add services, you only need to add implementation classes for implementing interfaces and distribute them in excutor;

 

IV [reflection ]--------------------
Now let's look at the figure:

We have noticed that I moved the IF-else statement in the loginservice to loadstrategyexcutor. Another method was to move the switch-case in loadstrategyexcutor back to loginservice, let loginservice directly make a judgment. Is this OK?

First of all, there is no difference in functionality, and the system will run normally. What is the difference? It is mainly a "division of duties" issue. In object-oriented programming, it focuses on a decoupling and delegation principle, hoping that the "not managed by yourself" part will not be handed over to your own management,

Here, we can find that loginservice acts as the client, and other classes fully enter the internal members of the "Policy mode. Loginserviceuses loadstrategyexcutor.exe cute (User) to call the entire "policy mode" module. In this way, the policy mode module receives the parameters passed by loginservice (the context is the Orthodox ), isolate the business logic from your own region and return the processing result.

Design Mode-policy Mode