A method for automatically switching implementation classes based on strategy mode

Abstract

The present invention discloses a method for implementing an automatic switching class based on a policy pattern, and belongs to the technical field of software development. A method for implementing an automatic switching class based on a policy pattern comprises the following steps: S1, setting a policy binding loader; S2, parsing the automatic loader configuration: when the system starts, all supported policy binding loaders are obtained from the application context, and the policy binding loader specified by the user is matched for loading; S3, loading policy binding data: loading the policy binding data into the policy context through the specified policy binding loader, and caching it into the JVM memory. The present invention replaces the complex policy selection logic judgment, encapsulates the algorithm in an independent policy, is easy to switch, easy to understand, easy to expand, and flexible to add new algorithm strategies.

Description

Technical Field

[0001] The present invention relates to the technical field of software development, and in particular to a method for automatically switching implementation classes based on a strategy pattern. Background Art

[0002] In the daily software development process, we often encounter the situation where different implementation logics are provided for a business function under different scenario requirements, so as to achieve the purpose of dynamically switching business algorithms and meeting different scenarios. For example, when sorting data, different sorting algorithms are selected according to different data structures; different login verification logics are used according to different clients; when placing orders from different promotion entrances, the order processing logic of each source is different; dynamically switching business algorithms according to different projects, etc.

[0003] For the above scenarios, our usual approach is to perform logical judgment through "if-else" statements to determine the matching execution logic for execution.

[0004] This leads to many problems, such as:

[0005] 1. Every time a new project is added, in order to support the processing strategy of this new source, the source code must be modified to add project judgment, which makes the application more and more large and difficult to maintain. At the same time, since the source program is modified, the application needs to be re-released, and the update will inevitably affect the ongoing services;

[0006] 2. Existing strategies cannot be reused;

[0007] 3. Too many "if-else" branches;

[0008] 4. Excessive coupling between logical judgment and business code;

[0009] 5. The newly added logic implementation cannot be extended elegantly. Summary of the invention

[0010] The purpose of the present invention is to solve the above problems in the prior art and to propose a method for automatically switching implementation classes based on a strategy pattern.

[0011] In order to achieve the above object, the present invention adopts the following technical solutions:

[0012] A method for automatically switching implementation classes based on a strategy pattern comprises the following steps:

[0013] S1, set the policy binding loader;

[0014] S2, parse the autoloader configuration: when the system starts, get all supported policy binding loaders from the application context, match the user-specified policy binding loader for loading;

[0015] S3, loading policy binding data: loads policy binding data into the policy context through the specified policy binding loader and caches it into the JVM memory.

[0016] Preferably, in step S3, the following steps are included:

[0017] S301, policy binding data conversion:

[0018] The policy context converts the loaded policy binding data into a collection of project and policy binding relationship data;

[0019] Among them, the project identifier and policy type are used as key values, and the specific policy implementation class is used as the value to quickly analyze and match specific data.

[0020] Preferably, in step S1:

[0021] The pre-set ones are: database strategy binding loader, annotation scanning strategy binding loader;

[0022] And provide user-defined policy binding loader.

[0023] Preferably, it is characterized in that:

[0024] In step S2, the corresponding policy binding loader is selected by parsing the user configuration;

[0025] In step S3, the loading method in the policy binding loader is executed to load the policy binding data into the policy context and cache it into the JVM memory.

[0026] Preferably, in step S301:

[0027] The data structure of the project and strategy binding relationship set data is project identifier, strategy type full class name, and strategy implementation class full class name;

[0028] This ensures the uniqueness of the set data of the project and policy binding relationship and avoids anomalies caused by duplication of policy binding data.

[0029] Preferably, in step S3, for the database policy binding loader:

[0030] The database driver is used to load the policy binding data that has been arranged in the specified database and load the data into the policy context.

[0031] Preferably, in step S3, for the annotation scanning strategy binding loader:

[0032] Implement the policy binding annotation on the class through scanning strategy and parse the value attribute in the annotation;

[0033] The value attribute value is an array of project identifiers. Each strategy implementation class can be bound to multiple projects through annotations.

[0034] Through the above operations, the project is associated with the specific policy implementation class and loaded into the policy context.

[0035] Preferably, in step S3, for the user-defined policy binding loader:

[0036] Users implement the system policy binding loader interface to implement a custom policy binding loader, and override the load method to load the assembled policy binding data into the policy context as a return value.

[0037] Preferably, in step S3, it also includes:

[0038] At runtime, the strategy is adjusted dynamically.

[0039] Preferably, the dynamic adjustment strategy includes the following steps:

[0040] Dynamically modify the binding relationship between the project and the policy implementation class, reload the policy binding data into the policy context through the policy binding loader, and implement dynamic replacement.

[0041] Compared with the prior art, the present invention provides a method for automatically switching implementation classes based on a strategy pattern, which has the following beneficial effects.

[0042] 1. The present invention provides different implementation logics under different project requirements to achieve dynamic switching of business algorithms; it separates it from a large number of logical judgments, decouples the algorithm from the actual business code, and shields the underlying implementation logic from the user.

[0043] 2. The present invention automatically loads the project and policy binding relationship by using the policy binding loader in the automatic loader. The user can use the policy provider to obtain the policy implementation class corresponding to the project binding by displaying the specified project identifier and policy type.

[0044] 3. The present invention replaces the complex strategy selection logic judgment, avoids the use of multiple conditional "if-else" statements, and improves code readability and maintainability.

[0045] 4. The present invention perfectly supports the open-closed principle and encapsulates the algorithm in an independent strategy without modifying the source code, making it easy to switch, easy to understand, easy to expand, and flexible to add new algorithm strategies.

[0046] 5. In the present invention, users can dynamically adjust the binding relationship between projects and implementation strategies according to different time and business requirements to achieve high flexibility.

[0047] Other advantages, objectives and features of the present invention will be described in part in the following description; and in part, will be apparent to those skilled in the art based on an examination of the following; or, may be taught from the practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 Load the flow chart for the policy binding.

[0049] Figure 2 Get a flow chart for your strategy. DETAILED DESCRIPTION

[0050] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, rather than all the embodiments.

[0051] Reference Figure 1-2 , a method for automatically switching implementation classes based on a strategy pattern, comprising the following steps:

[0052] S1, set the policy binding loader;

[0053] S2, parse the autoloader configuration;

[0054] S3, loads policy binding data.

[0055] By using the policy binding loader in the automatic loader, the project and policy binding relationship are automatically loaded; the user can use the policy provider to obtain the policy implementation class corresponding to the project binding by displaying the specified project ID and policy type.

[0056] The specific steps of the present invention are as follows.

[0057] In step S1, a strategy binding loader (StrategyBindingLoader) is set: the user pre-sets the strategy binding loader for calling.

[0058] For example, there are two default loaders: database strategy binding loader and annotation scanning strategy binding loader.

[0059] At the same time, in order to improve applicability, a user-defined policy binding loader is also provided for further expansion.

[0060] In step S2, the autoloader configuration is parsed.

[0061] When the system starts, all supported policy binding loaders are obtained from the application context, and the policy binding loader specified by the user is matched for loading.

[0062] That is, by parsing the user configuration, the corresponding policy binding loader is selected.

[0063] Afterwards, proceed to step S3 to load the policy binding data.

[0064] The strategy binding data is loaded into the strategy context (StrategyContext) through the specified strategy binding loader and cached in the JVM memory.

[0065] That is, the loading method in the policy binding loader is executed to load the policy binding data into the policy context.

[0066] In step S3, the following steps are included:

[0067] S301, policy binding data conversion.

[0068] The strategy context converts the loaded strategy binding data into a collection of project and strategy binding relationship data (StrategyBinding).

[0069] Among them, the project identifier and policy type are used as key values, and the specific policy implementation class is used as the value to quickly analyze and match specific data.

[0070] That is, the Strategy Provider is used as a tool for obtaining strategy implementations. By using the project ID and strategy type as parameters, the Strategy Provider can automatically analyze the match and provide a specific strategy implementation class.

[0071] StrategyProvider is a strategy acquirer exposed to users. Its main function is to parse the project and strategy type specified by the user, obtain the full class name of the matching strategy implementation class from the strategy context, and obtain the specific strategy implementation class through reflection and provide it to users.

[0072] Correspondingly, the data structure of the project and policy binding relationship set data is the project identifier, the full class name of the policy type, and the full class name of the policy implementation class; this ensures the uniqueness of the project and policy binding relationship set data and avoids anomalies caused by duplication of policy binding data.

[0073] The following describes the three types of policy binding loaders.

[0074] In step S3: For the database policy binding loader:

[0075] The database driver is used to load the policy binding data that has been arranged in the specified database and load the data into the policy context.

[0076] In step S3: For the annotation scanning strategy binding loader:

[0077] The strategy binding annotation (@StrategyBinding) on ​​the scanning strategy implementation class is parsed to resolve the value attribute in the annotation.

[0078] The value of the value attribute is an array of project identifiers, which means that each policy implementation class can be bound to multiple projects through annotations. Through the above operations, the project is associated with the specific policy implementation class and loaded into the policy context.

[0079] In step S3: For the user-defined policy binding loader:

[0080] Users implement the system policy binding loader interface to implement a custom policy binding loader, and override the load method to load the assembled policy binding data into the policy context as a return value.

[0081] Furthermore, in step S3, it also includes:

[0082] At runtime, the strategy is adjusted dynamically.

[0083] Specifically, it supports dynamic modification of the binding relationship between the project and the policy implementation class at runtime; reloads the policy binding data into the policy context through the policy binding loader to achieve dynamic replacement.

[0084] The present invention provides different implementation logics for the same business function under different project requirements, thereby realizing dynamic switching of business algorithms; it is freed from a large number of logical judgments, decouples the algorithm from the actual business code, and shields the underlying implementation logic from users.

[0085] The present invention provides a method for automatically switching implementation classes based on a strategy pattern, which is used to solve the problems in the prior art of code coupling, low scalability, and possible logic judgment errors caused by writing a large number of logic judgments in the code due to the gradual increase in the number of projects.

[0086] Thus, the following objectives are achieved:

[0087] 1. Automatically scan the relationship between binding projects and policy implementation classes;

[0088] 2. Automatically load project and strategy implementation class relationships from the database;

[0089] 3. Provide custom loader, which can be customized by users to implement project strategy binding;

[0090] 4. Support automatic matching and return of specific policy implementation classes bound to projects based on project identification and policy type.

[0091] In the present invention, the policy binding loader in the automatic loader is used to automatically load the binding relationship between the project and the policy. The user can use the policy provider to obtain the policy implementation class corresponding to the project binding by displaying the specified project identifier and policy type; it replaces the complex policy selection logic judgment, avoids the use of multiple conditional "if-else" statements, and improves the readability and maintainability of the code; it perfectly supports the open-closed principle, and encapsulates the algorithm in an independent policy without modifying the source code, making it easy to switch, easy to understand, easy to expand, and flexible to add new algorithm strategies; users can dynamically adjust the binding relationship between the project and the implementation strategy according to different time and business requirements to achieve high flexibility.

[0092] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A method for automatically switching implementation classes based on a strategy pattern, characterized in that: The following steps are involved: S1, set the policy binding loader; S2, parse the autoloader configuration: when the system starts, obtain all supported policy binding loaders from the application context, match the user-specified policy binding loader for loading; In step S2, the corresponding policy binding loader is selected by parsing the user configuration; S3, load policy binding data: load policy binding data into the policy context through the specified policy binding loader and cache it into the JVM memory; In step S3, the policy binding data is loaded into the policy context by executing the loading method in the policy binding loader; In step S1, the following are pre-set: a database policy binding loader, an annotation scanning policy binding loader; and a user-defined policy binding loader is provided; In step S3, the following steps are included: S301, policy binding data conversion: the policy context converts the loaded policy binding data into project and policy binding relationship set data; wherein, the project identifier and policy type are used as key values, and the specific policy implementation class is used as the value, so as to quickly analyze and match the specific data; In step S301: the data structure of the project and policy binding relationship set data is project identification, policy type full class name, policy implementation class full class name; to ensure the uniqueness of the project and policy binding relationship set data and avoid anomalies caused by duplication of policy binding data.

2. The method for implementing automatic switching based on the strategy pattern according to claim 1, characterized in that: In step S3, for the database policy binding loader: The database driver is used to load the policy binding data that has been arranged in the specified database and load the data into the policy context.

3. The method for implementing automatic switching based on strategy mode according to claim 1, characterized in that: In step S3, for the annotation scanning strategy binding loader: Implement the policy binding annotation on the class through scanning strategy and parse the value attribute in the annotation; The value attribute value is an array of project identifiers. Each strategy implementation class can be bound to multiple projects through annotations. Through the above operations, the project is associated with the specific policy implementation class and loaded into the policy context.

4. The method for implementing automatic switching based on strategy mode according to claim 1, characterized in that: In step S3, for the user-defined policy binding loader: Users implement the system policy binding loader interface to implement a custom policy binding loader, and override the load method to load the assembled policy binding data into the policy context as a return value.

5. The method for implementing automatic switching based on strategy mode according to claim 1, characterized in that: In step S3, it also includes: At runtime, the strategy is adjusted dynamically.

6. The method for implementing automatic switching based on strategy mode according to claim 5, characterized in that: Dynamically adjusting the strategy includes the following steps: Dynamically modify the binding relationship between the project and the policy implementation class, reload the policy binding data into the policy context through the policy binding loader, and implement dynamic replacement.

Images