策略模式在数据接收和发送场景的应用
在本篇文章中，我们介绍了策略模式，并在数据接收和发送场景中使用了策略模式。
if("A".equals(system)){ASystem.sync("向A同步数据");}if("B".equals(system)){BSystem.sync("向B同步数据");}...
这样设计有什么样的问题呢？首先随着外部系统接入越来越多，不具备良好的扩展性，会导致代码越来越臃肿，其次从软件的设计角度来看, 不符合单一职责原则, 也不符合开闭原则。
那么选择什么样的设计模式来解决if else 堆砌的问题呢？首先我想到了策略模式。
首先我们来看一下策略模式的定义：
策略模式（Strategy Pattern）定义了一组同类型的算法，在不同的类中封装起来，每种算法可以根据当前场景相互替换，从而使算法的变化独立于使用它们的客户端（即算法的调用者）
那么代入到我们的需求场景，我需要向外部系统同步或接收数据，数据的类型决定了我需要同步给A系统或者B系统，这些不同的数据决定了不同的策略
策略模式的结构通常包括以下组成部分：
定义一个策略接口或抽象类：该接口或抽象类定义了所有策略类都需要实现的方法。
创建多个具体的策略类：每个具体的策略类都实现了策略接口或抽象类，并提供了不同的实现。
创建一个策略上下文类：该类负责使用策略，它通常会维护一个策略接口或抽象类的引用。
在客户端代码中使用策略上下文类：客户端代码可以根据需要选择不同的策略。
看定义有些抽象，下面的结构图应该会容易理解一些。
public interface DataProcessingStrategy {void receiveData();void sendData();}
2.为每个外部系统创建一个策略类：
public class ASystemDataProcessingStrategy implements DataProcessingStrategy {@Overridepublic void receiveData() {// 接收数据的具体实现}@Overridepublic void sendData() {// 发送数据的具体实现}}
public class BSystemDataProcessingStrategy implements DataProcessingStrategy {@Overridepublic void receiveData() {// 接收数据的具体实现}@Overridepublic void sendData() {// 发送数据的具体实现}}
public class Context {private DataProcessingStrategy strategy;public Context(DataProcessingStrategy strategy) {this.strategy = strategy;}public void setStrategy(DataProcessingStrategy strategy) {this.strategy = strategy;}public void sendData(String data) {strategy.sendData(data);}public String receiveData() {return strategy.receiveData();}}
public class Main {public static void main(String[] args) {// 创建两个策略对象DataProcessingStrategy strategyA = new ASystemDataProcessingStrategy();DataProcessingStrategy strategyB = new BSystemDataProcessingStrategy();// 创建上下文对象，并传入策略对象Context context = new Context(strategyA);//使用 ASystemDataProcessingStrategy 请求和接收数据context.sendData("");context.receiveData("");// 使用 BSystemDataProcessingStrategy 请求和接收数据context = new Context(strategyB);context.sendData("");context.receiveData("");}}
升级为策略模式+工厂模式
硬编码的依赖关系：在上述代码中，我们直接将具体的策略类（例如StrategyA和StrategyB）硬编码到上下文类（Context）中。这意味着如果我们想要添加或修改策略，我们需要在上下文类中修改代码。这种硬编码的方式使得系统难以扩展和维护。 客户端与策略的具体实现紧密耦合：由于上下文类Context直接依赖于具体的策略类，因此客户端代码必须了解每个具体策略的细节。这增加了客户端代码的复杂性，并使得客户端代码与策略的具体实现紧密耦合，增加了代码的维护难度。
// 策略接口和具体的策略类保持不变public interface DataProcessingStrategy {void sendData(String data);String receiveData();}public class ASystemDataProcessingStrategy implements DataProcessingStrategy {public void sendData(String data) {// 发送数据到系统A的实现}public String receiveData() {// 从系统A接收数据的实现}}public class BSystemDataProcessingStrategy implements DataProcessingStrategy {public void sendData(String data) {// 发送数据到系统B的实现}public String receiveData() {// 从系统B接收数据的实现}}public class DataProcessingStrategyFactory {private static ConcurrentHashMap<String, DataProcessingStrategy> strategies = new ConcurrentHashMap<>();/*** 注册策略* @param strategyName* @param strategy*/public static void register(String strategyName, DataProcessingStrategy strategy) {strategies.put(strategyName, strategy);}public static DataProcessingStrategy getStrategy(String strategyName) {return strategies.get(strategyName);}}//client类相关修改public class Main {public static void main(String[] args) {DataProcessingStrategy systemA = DeployStrategyFactory.getStrategy("A");//使用 ASystemDataProcessingStrategy 请求和接收数据systemA.sendData("");systemA.receiveData("");DataProcessingStrategy systemB = DeployStrategyFactory.getStrategy("B");// 使用 BSystemDataProcessingStrategy 请求和接收数据systemB.sendData("");systemB.receiveData("");}}
在本篇文章中，我们介绍了策略模式，并在数据接收和发送场景中使用了策略模式。通过使用策略模式，我们可以在客户端代码中根据运行时条件动态地选择一个具体的策略类，并通过这个策略类来改变对象的行为。这样，我们就可以实现不同的数据接收和发送方式，而不需要在客户端代码中进行大量的if-else判断。同时通过策略模式+工厂模式的方式解决了客户端代码与策略的具体实现紧密耦合的问题。当然结合实际的场景灵活运用相应的设计模式也非常重要，避免过度设计。
我们是淘天集团-天猫奢品技术团队。天猫奢品汇聚全球顶尖品牌，覆盖全品类的高质量生活方式，致力于打造奢侈品线上消费首选平台。依托淘宝天猫电商生态，不断探索契合奢侈品品牌的互联网新体验技术与解决方案，以更加智能、友好的科技帮助品牌更好的经营，让用户享受更好的消费体验。