Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to kill if else". In daily operation, I believe many people have doubts about how to kill if else. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how to kill if else"! Next, please follow the editor to study!

Universal realization of responsibility chain

Now I default that everyone knows what is the chain of responsibility model, if you still do not understand this student, you can first take a look at my previous article.

First of all, we will have a business executor interface, which will be implemented by all business implementations, which means that logic A, B, and C in the figure above will implement this interface.

/ * Business executor * @ author crooked * / public interface BusinessProcess {void process (ProcessContext context);}

What you can see is that the interface is exceptionally simple, there is only one process handling method, and the method receives ProcessContext

Why does the process method need to receive ProcessContext? Quite simply, when we deal with logic A, B, C, it is possible that logic B depends on the processing result of logic A. So we need a carrier to record this.

So, we have ProcessContext, which represents the context of the chain of responsibility.

/ * * chain of responsibility context * @ author 3y * / public class ProcessContext {/ / identifies the code private String code; of the chain of responsibility / / the real carrier of the storage context private Model model; / / the identification of the chain of responsibility break private Boolean needBreak = false;}

Now the executor of the chain of responsibility and the context involved in the chain of responsibility are in place, which means that we already have the main abstraction of the chain of responsibility.

The next thing is that we need to string the chain together, so we need a template, but what we do is use a List to string together the subclasses of BusinessProcess.

/ * Business execution template (stringing together the logic of the responsibility chain) * @ author 3y * / public class ProcessTemplate {private List processList; public List getProcessList () {return processList;} public void setProcessList (List processList) {this.processList = processList;}}

OK, now that we've abstracted the whole piece of the chain of responsibility, it's time to expose the process controller to execute the chain of responsibility:

/ * * the process controller of the chain of responsibility (general control of the execution process of the whole chain of responsibility) * @ author 3y * / @ Data public class ProcessController {/ / different code corresponds to different chain of responsibility private Map templateConfig = null; public void process (ProcessContext context) {/ / execute different chain of responsibility String businessCode = context.getCode () according to the Code of the context ProcessTemplate processTemplate = templateConfig.get (businessCode); List actionList = processTemplate.getProcessList (); / / traversing the process node of a chain of responsibility for (BusinessProcess action: actionList) {try {action.process (context); if (context.getNeedBreak ()) {break }} catch (Exception e2) {/ /...}

What we can see is that there is a Map to store templates for multiple chains of responsibility on the common process controller of the ProcessController execution chain. the advantage of this is that the process controller ProcessController can support multiple chains of responsibility according to code.

Next, we have a specific BusinessProcess to add to the chain of ProcessTemplate, and then call the method of ProcessController to execute the entire push chain.

Generally speaking, we can just inject it into XML. For example, we now have two implementations of BusinessProcess, whitelist and messaging logic:

/ * whitelist processor * @ author 3y * / @ Service public class WhiteListProcess implements BusinessProcess {@ Override public void process (ProcessContext context) {UserModel user = (UserModel) context.getModel (); if ("3y" .equals (user.getName () {context.setNeedBreak (true) } / * messaging processor * @ author * / @ Service public class SendMessageProcess implements BusinessProcess {@ Override public void process (ProcessContext context) {UserModel user = (UserModel) context.getModel (); System.out.println ("to" + user.getName () + "send a message");}}

Then we add the above two processors to the template of ProcessTemplate and the ProcessTemplate to the Map of ProcessController:

Then we execute this chain of responsibility in the interface:

@ RestController public class UserController {@ Autowired private ProcessController processController; @ RequestMapping ("/ send") public void send (String userName) {/ / build context ProcessContext processContext = new ProcessContext (); UserModel userModel = new UserModel (); userModel.setAge ("24"); userModel.setName (userName); processContext.setModel (userModel); processContext.setCode ("sendMessage") ProcessController.process (processContext);}}

What function did I achieve when I made such a big set of things? In fact, there is only one if logic:

If ("3y" .equals (userModel.getName () {return;} System.out.println ("send" + userModel.getName () + "send a message")

Let's take a look at the effect. Functionally, we can find that as long as we don't enter "3y", the message will be printed.

The above logic is actually a set of code for a general chain of responsibility. the core is actually four roles: "business abstract interface", "context during execution", "stringing business implementation classes together" and "a general controller execution responsibility chain"

If you do not understand the students, three crooked suggest to compare the code to see, the responsibility chain design pattern is very easy to use, in the project is also very common.

Just copy the BusinessProcess/ProcessContext/ProcessTemplate/ProcessController code to your own project, and this will help you kill the original if else logic.

Pipeline

I don't know if you have seen the word Pipeline. We may have seen it when learning Redis. In Redis, we will use Pipeline to do batch operations.

Put aside Redis's Pipeline, but from a macro point of view, Pipeline is actually a kind of architectural thought.

At the same time, I also think it is one of the implementations of the "chain of responsibility model".

Let's take a look at the architecture diagram of a Pipeline implementation on my side:

At this point, the study on "how to kill if else" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.