Interviewer: I would like to ask a question, a common question in a project

Interviewer: I now have a system that does different things depending on the entry request. However, this different action is likely to change the requirements, this system you will design?

Interviewer: Practical example: There are multiple third-party channels and the system needs to make order attributions for each channel. However, the logic of attribution is likely to change, and the logic of attribution is not quite the same in different channels, so the logic in the system is relatively complex.

Interviewer: If you could optimize it, how would you design it?

Candidate: I see what you mean

Candidates: In the final analysis, the logic of processing is relatively complex, and there are too many if and else judgments

Candidate: New requirements can be addressed by adding if else

Candidates: But what you want is more scalable and maintainable

Candidate: Wants me to come up with a solution to a similar problem

Candidate: Right?

Interviewer: HMM…

Candidate: Before this, how do you solve the if else, most of which is the strategy mode

Candidate: But the examples are not empathy, a lot of times just over the past

Candidates: In fact, policy patterns are often used in projects, and may have been inadvertently used (after all, interface oriented programming).

Candidate: In my opinion, the strategic pattern is not the key to solving if else

Candidate: The way I approach this question in my project is: chain of responsibility

Candidate: Extract each Process individually into a Process(which can be interpreted as a module or node), and then the requests are stuffed into the Context

Candidates: For example, having previously maintained a project is similar to following different logic for different channels

Candidate: Our approach is to extract relevant logic into the Process and assign different responsibility chains for different channels

Candidate: For example, channel A’s chain of responsibility is WhiteListProcess->DataAssembleProcess->ChannelAProcess->SendProcess

Candidate: And channel B’s chain of responsibility is WhiteListProcess->DataAssembleProcess->ChannelBProcess->SendProcess

Candidate: Build “scripts” into the code on top of the chain of responsibility

Candidate: In SendProcess, for example, a script is built in to send messages (the script can select different carriers to send messages). With scripts, changes to the logic can take effect without a reboot.

Candidate: Some call this a “rules engine.” For example, the well-known implementation framework “Drools” in the rules engine can do something similar

Candidate: Write mutable logic on “scripts” (at least we think scripts are separate from the real logic of our application)

Candidate :(script, by which I mean rule set, could be a Drools DSL, Groovy, aviator, etc.)

Interviewer: HMM…

Candidate: At my previous company, Groovy scripts were used. The implementation logic is as follows: A special background manages the scripts, and then the scripts are written to the distributed configuration center (real-time refresh). The client monitors whether the scripts stored in the distributed configuration Center are changed

Candidate: If there are changes, the script is recompiled and loaded through the Groovy classloader, and then released to the Spring container for external use

Candidate: This is how the system I am currently in charge of handles a business with variable and frequently changing requirements (chain of responsibility + rules engine)

Candidate: But as I understand it, our gameplay business is doing a little more in the chain of responsibility

Candidate: The chain of responsibility is no longer written in code, but is sunk into the platform to do “service choreography”, where programmers configure information on the “service choreography background” (configure each node in the chain of responsibility).

Candidates: Clients using Service Choreography in a business system can execute code as a service choreography flow by passing in a service choreography ID when requesting it

Candidate: The advantage of this is that the business chain is configured in the background, and there is no need to maintain the chain on the system business, which is more flexible (the written responsibility chain nodes can be combined at will).

Interviewer: I see

Welcome to follow my wechat official account [Java3y] to talk about Java interview, on line interview series continue to update!

Online Interviewer – Mobile seriesTwo continuous updates a week!

Line – to – line interviewers – computer – end seriesTwo continuous updates a week!

Original is not easy!! Three times!!