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

With regard to design patterns, if used properly, our code will be more concise and more extensible. This article mainly explains how to use the policy pattern, factory method pattern and Builder pattern in Spring.

1. Strategy mode

With regard to the use of the policy pattern, it is actually relatively simple in Spring. In essence, the policy pattern is that there are multiple implementation classes under an interface, and each implementation class handles a certain situation. We take the award as an example to explain, for example, we have a variety of reward methods to choose from in the lottery system, such as points, virtual coins and cash. When storing, we are bound to use a field similar to type to represent these awards, so here we can use polymorphism to distribute awards. For example, we abstract an interface of PrizeSender, which is declared as follows:

Public interface PrizeSender {/ * is used to determine whether the current instance supports the issuance of the current award * / boolean support (SendPrizeRequest request); / * award * / void sendPrize (SendPrizeRequest request);}

There are mainly two methods in this interface: support () and sendPrize (), in which the support () method is mainly used to determine whether each subclass supports the processing of the current type data, while sendPrize () is mainly used for specific business processing, such as the distribution of awards here. Here are the specific codes for our three different types of awards:

/ / Componentpublic class PointSender implements PrizeSender {@ Override public boolean support (SendPrizeRequest request) {return request.getPrizeType () = = PrizeTypeEnum.POINT;} @ Override public void sendPrize (SendPrizeRequest request) {System.out.println ("issuing points");}} / / Virtual currency issue @ Componentpublic class VirtualCurrencySender implements PrizeSender {@ Override public boolean support (SendPrizeRequest request) {return PrizeTypeEnum.VIRTUAL_CURRENCY = = request.getPrizeType () } @ Override public void sendPrize (SendPrizeRequest request) {System.out.println ("issuing virtual coins");} / / Cash distribution @ Componentpublic class CashSender implements PrizeSender {@ Override public boolean support (SendPrizeRequest request) {return PrizeTypeEnum.CASH = = request.getPrizeType ();} @ Override public void sendPrize (SendPrizeRequest request) {System.out.println ("cash");}}

As you can see, in each subtype, we only need to control whether the current request is a type that the current instance can handle through a parameter of request in the support () method. If so, the outer control logic will hand over the request to the current instance for processing. There are several points to note about the design of this class:

Annotate the current class with the @ Component annotation, declaring it as a bean managed by the Spring container

Declares a method similar to support () that returns a Boolean value, which controls whether the current instance is an instance that processes the target request

Declare a method similar to sendPrize () to deal with business logic. Of course, the method name must be different according to the different declaration of each business. This is just an abstraction of unified business processing.

Whether it is the support () method or the sendPrize () method, you need to pass an object instead of a simple basic type of variable. the advantage of this is that if you add fields to the Request later, you do not need to modify the definition of the interface and the logic of each subclass that has been implemented.

two。 Factory method model

Above we explained how to use Spring to declare a policy pattern, so how to inject different bean for different business logic, or what the outer control logic looks like, here we can use the factory method pattern. The so-called factory method pattern is to define a factory method, return an instance through the passed parameters, and then process the subsequent business logic through that instance. In general, the return value type of a factory method is an interface type, while the logic of selecting a specific subclass instance is encapsulated in the factory method. In this way, the outer calling logic is separated from the acquisition logic of the specific subclass. The following figure shows a schematic diagram of the factory method pattern:

As you can see, the factory method encapsulates the selection of the specific instance, while the client, that is, our caller, only needs to call the specific method of the factory to get the specific case, regardless of what the specific instance implementation is. Above we explained how to use the policy pattern declaration processing logic in Spring, without talking about how to select a specific policy, here we can use the factory method pattern. The following is a PrizeSenderFactory we declared:

Componentpublic class PrizeSenderFactory {@ Autowired private List prizeSenders; public PrizeSender getPrizeSender (SendPrizeRequest request) {for (PrizeSender prizeSender: prizeSenders) {if (prizeSender.support (request)) {return prizeSender;}} throw new UnsupportedOperationException ("unsupported request:" + request);}}

Here we declare a factory method getPrizeSender (), whose input parameter is SendPrizeRequest, and the return value is an instance that implements the PrizeSender interface. As you can see, in this way, we move down the specific selection method to a specific subclass, because whether the bean that currently implements PrizeSender supports the current request processing is implemented by the specific subclass. In this factory method, we also do not have any logic related to a specific subclass, that is, the class can actually dynamically detect newly added subclass instances. This is mainly achieved through the automatic injection of Spring, mainly because what we are injecting here is a List, that is, if there is a new subclass instance of PrizeSender, as long as it is managed by Spring, it will be injected here. Here is a piece of code we wrote for testing to simulate the caller's call:

@ Servicepublic class ApplicationService {@ Autowired private PrizeSenderFactory prizeSenderFactory; public void mockedClient () {SendPrizeRequest request = new SendPrizeRequest (); request.setPrizeType (PrizeTypeEnum.POINT); / / the request here is generally generated from the database or external calls to PrizeSender prizeSender = prizeSenderFactory.getPrizeSender (request); prizeSender.sendPrize (request);}}

In the client code, we first obtain a PrizeSender instance through PrizeSenderFactory, and then issue a specific reward through its sendPrize () method, which decouples the specific reward issuing logic from the client call. And from the previous explanation, we also know that if a new reward is added, we only need to declare a new bean that implements PrizeSender without any changes to the existing code.

3. Builder mode

With regard to the Builder pattern, I think students who have used lombok will certainly say that the builder pattern is very simple, just declare it with the @ Builder annotation on a bean, and lombok can automatically declare it as a Builder bean for us. I am noncommittal about this mode of use, but as far as I understand it, there are two main points we need to understand:

As far as its name is concerned, the Builder schema is a builder, and I prefer to understand it as the final generation of an object through certain parameters and business logic. If you only use lombok in this way, it essentially creates a simple bean, which is not much different from building a bean through getter and setter.

In the Spring framework, the biggest problem with using design patterns is that if the bean of Spring can be injected into each pattern bean, if it can be injected, then its usage will be greatly expanded. Because we can actually implement a few simple parameters passed in, and then do some processing with the bean injected by Spring to construct a certain bean that we need. Obviously, this is what lombok cannot achieve.

With regard to the Builder pattern, we can take the structure of the SendPrizeRequest issued by the previous reward as an example. When constructing a request object, it must be through some parameters transmitted in the foreground to go through certain processing, and finally generate a request object. Then we can use the Builder pattern to build a SendPrizeRequest. Assuming that according to the foreground call, we can get prizeId and userId, then we can create a SendPrizeRequest as follows:

Public class SendPrizeRequest {private final PrizeTypeEnum prizeType; private final int amount; private final String userId; public SendPrizeRequest (PrizeTypeEnum prizeType, int amount, String userId) {this.prizeType = prizeType; this.amount = amount; this.userId = userId;} @ Component @ Scope ("prototype") public static class Builder {@ Autowired PrizeService prizeService; private int prizeId; private String userId; public Builder prizeId (int prizeId) {this.prizeId = prizeId; return this } public Builder userId (String userId) {this.userId = userId; return this;} public SendPrizeRequest build () {Prize prize = prizeService.findById (prizeId); return new SendPrizeRequest (prize.getPrizeType (), prize.getAmount (), userId);}} public PrizeTypeEnum getPrizeType () {return prizeType;} public int getAmount () {return amount;} public String getUserId () {return userId;}}

Here is an example of using Spring to maintain a Builder schema by tagging the Builder class with @ Component and @ Scope annotations on the Builder class, so that we can inject the instances we need into the Builder class to do some business processing. Here are a few points to explain about this pattern:

The @ Scope annotation must be used on the Builder class to mark the instance as prototype, because it is clear that our Builder instance here is stateful and cannot be shared by multi-threads.

In the Builder.build () method, we can do some business processing through the passed parameters and the injected bean to get the parameters needed to build a SendPrizeRequest.

The Builder class must be decorated with static, because in Java, if the inner class is not decorated with static, then the instance of the class must depend on an instance of the external class, and here we essentially want to build the external class instance through the internal class instance, that is, when the internal class instance exists, the external class instance does not exist, so we must use static decoration here.

Depending on how the standard Builder schema is used, the parameters of the external class must be decorated with final, and then you just need to declare the getter method for it.

Above we showed how to use Spring to declare a class of Builder schema, so how do we use it? here is an example of our use:

@ Servicepublic class ApplicationService {@ Autowired private PrizeSenderFactory prizeSenderFactory; @ Autowired private ApplicationContext context; public void mockedClient () {SendPrizeRequest request = newPrizeSendRequestBuilder () .prizeId (1) .UserID ("u4352234") .build (); PrizeSender prizeSender = prizeSenderFactory.getPrizeSender (request); prizeSender.sendPrize (request);} public Builder newPrizeSendRequestBuilder () {return context.getBean (Builder.class);}}

In the above code, we mainly want to look at the newPrizeSendRequestBuilder () method. In Spring, if a class is a multi-instance type, that is, marked with @ Scope ("prototype"), then every time you get the bean, you must use the ApplicationContext.getBean () method to get a new instance. As for the specific reasons, readers can consult the relevant documentation. Here we create a Builder object through a separate method, then set parameters such as prizeId and userId for it through streaming, and finally get a SendPrizeRequest instance through the build () method, through which subsequent rewards are distributed.

4. Summary

This article mainly uses an example of reward distribution to explain how to use factory method pattern, policy pattern and Builder pattern in Spring, and emphasizes the points we need to pay attention to when implementing each pattern.

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.