Java geek
Related reading:
JAVA programming ideas (1) To increase the extensibility of JAVA programming ideas (2) To interface programming ideas (3) to remove the awkward if, The self-registration policy pattern satisfies the open and closed principle gracefully. (5) The event notification pattern decoupling process. (6) The singleton pattern uses the Java programming idea. (7) The Combination and inheritance scenarios Java concurrent programming introduction (eleven) stream limiting scenarios and Spring stream limiting implementation HikariPool source code (two) design ideas for reference in the workplace (a) IT factory survival rules
1. Examples of policy pattern prototypes
Now to implement a tax calculation strategy, the tax calculation types are in-price tax and out-of-price tax, and new tax types may be added in the future. The initial design structure of the class is as follows:
| class | Duties and responsibilities |
|---|---|
| TaxStrategy | Tax Policy Interface |
| InterTaxStrategy | In-price tax strategy, responsible for the calculation of in-price tax |
| OuterTaxStrategy | Pricing tax strategy, responsible for pricing tax calculation |
| TaxType | Tax type definition, currently only in-price tax and out-of-price tax |
| TaxStrategyFactory | Tax strategy factory, according to the tax type to obtain different tax strategy to calculate the tax |
Code 2.
2.1. Tax policy code
public interface TaxStrategy {
double calc(long amount);
}
class InterTaxStrategy implements TaxStrategy {
@Override public double calc(long amount) {
final double taxRate = 0.2; // Obtain the tax rate
returnamount * taxRate; }}class OuterTaxStrategy implements TaxStrategy {
@Override public double calc(long amount) {
final double taxRate = 0.2; // Obtain the tax rate
return amount / (1+ taxRate) * taxRate; }}// Tax type definition
public enum TaxType {
INTER, OUTER
}
Copy the code2.2. Tax policy factory implemented by the IF statement
// Tax strategy factory
public class TaxStrategyFactory {
public static TaxStrategy getTaxStrategy(TaxType taxType) throws Exception {
// When new tax types are added, code changes are required and cyclomatic complexity increases
if (taxType == TaxType.INTER) {
return new InterTaxStrategy();
} else if (taxType == TaxType.OUTER) {
return new OuterTaxStrategy();
} else {
throw new Exception("The tax type is not supported."); }}}Copy the codeAs you can see, if you use the if statement to get different tax policies, you have to modify the existing code when you add a new tax policy, which is less attractive when there are many tax methods and increases cyclomatic complexity.
2.3. Map is used to replace IF in the first optimization of tax strategy factory
public class MapTaxStrategyFactory {
// The storage tax policy
static Map<TaxType, TaxStrategy> taxStrategyMap = new HashMap<>();
// Register the default tax policy
static {
registerTaxStrategy(TaxType.INTER, new InterTaxStrategy());
registerTaxStrategy(TaxType.OUTER, new OuterTaxStrategy());
}
// Provide a tax registration policy interface. External users only need to call this interface to add a tax policy without modifying the internal code of the policy factory
public static void registerTaxStrategy(TaxType taxType, TaxStrategy taxStrategy) {
taxStrategyMap.put(taxType, taxStrategy);
}
// Obtain the tax policy from map. When adding a new tax policy, there is no need to modify the code. It is closed for modification, but open for extension
public static TaxStrategy getTaxStrategy(TaxType taxType) throws Exception {
// When adding new tax types, you need to change the code and increase cyclomatic complexity
if (taxStrategyMap.containsKey(taxType)) {
return taxStrategyMap.get(taxType);
} else {
throw new Exception("The tax type is not supported."); }}}Copy the codeAs you can see, after the evolution, the IF statement is gone, cyclomatic complexity is reduced, and the new policy is added by simply calling the policy registration interface. There is no need to change the code that gets the tax policy.
2.4. Automatic registration of secondary optimization policies
In the above implementation, to register a new tax policy, it is necessary to manually call the registration interface of MapTaxStrategyFactory. In this way, the existing code needs to be modified for each new tax policy, or an appropriate initial call point needs to be found to register the tax policy. How to perfectly comply with the open and close principle and close the modification, Open to extension?
After further optimization, the class structure is as follows:
| class | Duties and responsibilities |
|---|---|
| TaxStrategy | Tax policy interface, provide tax calculation interface, and self-registered to the tax policy factory |
| InterTaxStrategy | In-price tax strategy, responsible for the calculation of in-price tax |
| OuterTaxStrategy | Pricing tax strategy, responsible for pricing tax calculation |
| TaxType | Tax type definition, currently only in-price tax and out-of-price tax |
| AutoRegisterTaxStrategyFactory | Tax policy factory, according to the tax type to obtain different tax policies to calculate taxes, while providing a tax policy registration interface |
Here I look at the changed code:
Against 2.4.1. Tax policy
public interface TaxStrategy {
double calc(long amount);
// Add a self-registered interface
void register(a);
}
class InterTaxStrategy implements TaxStrategy {
@Override public double calc(long amount) {
final double taxRate = 0.2; // Obtain the tax rate
return amount * taxRate;
}
@Override public void register(a) {
// Register yourself with the policy factory
AutoRegisterTaxStrategyFactory.registerTaxStrategy(TaxType.INTER, this); }}class OuterTaxStrategy implements TaxStrategy {
@Override public double calc(long amount) {
final double taxRate = 0.2; // Obtain the tax rate
return amount / (1 + taxRate) * taxRate;
}
@Override public void register(a) {
// Register yourself with the policy factory
AutoRegisterTaxStrategyFactory.registerTaxStrategy(TaxType.OUTER, this); }}Copy the code2.4.2. Tax factory
import java.util.*;
import org.reflections.Reflections;
import org.reflections.scanners.SubTypesScanner;
import org.reflections.util.ClasspathHelper;
import org.reflections.util.ConfigurationBuilder;
public class AutoRegisterTaxStrategyFactory {
// The storage tax policy
static Map<TaxType, TaxStrategy> taxStrategyMap = new HashMap<>();
static {
// Registration tax policy
autoRegisterTaxStrategy();
}
// Obtain the tax policy from map. When adding a new tax policy, there is no need to modify the code. It is closed for modification, but open for extension
public static TaxStrategy getTaxStrategy(TaxType taxType) throws Exception {
// When adding new tax types, you need to change the code and increase cyclomatic complexity
if (taxStrategyMap.containsKey(taxType)) {
return taxStrategyMap.get(taxType);
} else {
throw new Exception("The tax type is not supported."); }}// Provide a tax registration policy interface. External users only need to call this interface to add a tax policy without modifying the internal code of the policy factory
public static void registerTaxStrategy(TaxType taxType, TaxStrategy taxStrategy) {
taxStrategyMap.put(taxType, taxStrategy);
}
// Automatic registration tax policy
private static void autoRegisterTaxStrategy(a) {
try {
// Find all tax policy subclasses by reflection for registration
Reflections reflections = new Reflections(new ConfigurationBuilder()
.setUrls(ClasspathHelper.forPackage(TaxStrategy.class.getPackage().getName()))
.setScanners(new SubTypesScanner()));
Set<Class<? extends TaxStrategy>> taxStrategyClassSet = reflections.getSubTypesOf(TaxStrategy.class);
if(taxStrategyClassSet ! =null) {
for(Class<? > clazz: taxStrategyClassSet) { TaxStrategy taxStrategy = (TaxStrategy)clazz.newInstance();// Call the self-registered method of the tax policytaxStrategy.register(); }}}catch (InstantiationException | IllegalAccessException e) {
// Define your own exception handlinge.printStackTrace(); }}}Copy the codeNote: The following dependencies need to be added to the reflection tool in your code.
<dependency>
<groupId>org.reflections</groupId>
<artifactId>reflections</artifactId>
<version>0.912.</version>
</dependency>
<dependency>
<groupId>org.dom4j</groupId>
<artifactId>dom4j</artifactId>
<version>2.11.</version>
<optional>true</optional>
</dependency>
Copy the codeUse 2.4.3.
public class DecisionDemo {
public static void main(String[] args) throws Exception {
TaxStrategy taxStrategy = AutoRegisterTaxStrategyFactory.getTaxStrategy(TaxType.INTER);
System.out.println(taxStrategy.calc(100)); }}Copy the codeSo far, when adding a new tax policy, there is no need to modify the existing tax policy factory code, basically perfect open closed principle, the only need to modify the tax type definition.
2.5. Three optimization to reduce coupling through annotations (suggested by netizen Gu Yuanyuan)
The basic idea is to use annotations on the tax policy to indicate which type of tax it is, and to automatically complete the registration of the tax policy according to the annotations in the tax policy factory without calling the registration interface of the tax policy factory in each tax policy. The class structure diagram is as follows:
Let’s look at the code that changed.
2.5.1. TaxTypeAnnotation. Java
import java.lang.annotation.*;
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE})
public @interface TaxTypeAnnotation {
TaxType taxType(a);
}
Copy the code2.5.2. Strategy class
The tax policy removes the registration method and adds the TaxTypeAnnotation annotation to identify the tax type.
public interface TaxStrategy {
double calc(long amount);
}
@TaxTypeAnnotation(taxType = TaxType.INTER)
class InterTaxStrategy implements TaxStrategy {
@Override public double calc(long amount) {
final double taxRate = 0.2; // Obtain the tax rate
returnamount * taxRate; }}@TaxTypeAnnotation(taxType = TaxType.OUTER)
class OuterTaxStrategy implements TaxStrategy {
@Override public double calc(long amount) {
final double taxRate = 0.2; // Obtain the tax rate
return amount / (1+ taxRate) * taxRate; }}Copy the code2.5.3. Factory class
public class AnnotationTaxStrategyFactory {
// The storage tax policy
static Map<TaxType, TaxStrategy> taxStrategyMap = new HashMap<>();
static {
registerTaxStrategy();
}
// Obtain the tax policy from map. When adding a new tax policy, there is no need to modify the code. It is closed for modification, but open for extension
public static TaxStrategy getTaxStrategy(TaxType taxType) throws Exception {
// When adding new tax types, you need to change the code and increase cyclomatic complexity
if (taxStrategyMap.containsKey(taxType)) {
return taxStrategyMap.get(taxType);
} else {
throw new Exception("The tax type is not supported."); }}// Automatic registration tax policy
private static void registerTaxStrategy(a) {
try {
// Find all tax policy subclasses by reflection for registration
Reflections reflections = new Reflections(new ConfigurationBuilder()
.setUrls(ClasspathHelper.forPackage(TaxStrategy.class.getPackage().getName()))
.setScanners(new SubTypesScanner()));
Set<Class<? extends TaxStrategy>> taxStrategyClassSet = reflections.getSubTypesOf(TaxStrategy.class);
if(taxStrategyClassSet ! =null) {
for(Class<? > clazz: taxStrategyClassSet) {// Find the tax type annotation to automatically complete the tax policy registration
if(clazz.isAnnotationPresent(TaxTypeAnnotation.class)) { TaxTypeAnnotation taxTypeAnnotation = clazz.getAnnotation(TaxTypeAnnotation.class); TaxType taxType = taxTypeAnnotation.taxType(); taxStrategyMap.put(taxType, (TaxStrategy)clazz.newInstance()); }}}}catch (InstantiationException | IllegalAccessException e) {
// Define your own exception handlinge.printStackTrace(); }}}Copy the codeThis approach reduces the dependence of tax strategy and tax factory, only need to focus on their own algorithm implementation, decoupling is the best.
2.6. Ultimate optimization and refinement of universal design patterns
In software system, similar to the above strategy algorithm will be a lot of, different tax policies, different encryption strategies, different strategies of XXX, etc., these can be unified abstraction again, extract the public interface of the strategy, strategy of the factory class, so there is no need for each strategy has a set of code realization, share a set of code is enough.
This abstract design pattern can be called the self-registration policy pattern, and the actual code is left to think it out.
3. Summary
- Map replaces IF for policy selection, which can improve scalability and reduce cyclomatic complexity.
- The self-registration policy model gracefully satisfies the open – closed principle, closed for modification and open for extension.
- The more familiar you are with basic Java features, such as the annotations feature used in this article, the better the solution. Therefore, you should learn more basic Features of JAVA at ordinary times, and do not think that you have enough to understand the new features, new features must have its advantages, such as performance, elegant coding, decoupling, and so on.
end.
