设计模式巡礼：多板适配案例解析与深度重构

theme: cyanosis

月黑风高，好兄弟发给我一个重构需求，咨询我的意见。

一、场景分析

开发的产品是需要运行到不同的定制Android板子，不同板子有对应的不同SDK提供的API，目前的业务端，业务流程基本是确定的，比如有业务流程为打开板子的某项开关（需求就是打开开关），对应在板子中可能存在A、B、C三个板子或者更多，其中板子都提供了打开开关S的方法，但是方法名称各不相同，目前在代码中的使用方式都是，创建一个服务于业务的工具类，在工具类中判断板子类型创建不同的SDK，并使用不同SDK的API完成这个需求。

对于商业SDK的开发及多SDK使用，我有丰富的设计经验，面对这个问题，立马能说出这个描述中存在的问题有多少，所以意见是重构！必须重构。

1.1 存在问题

我从来都是以理服人，必须要着说明为什么重构，怎么重构，结果是什么.

1.2 还原代码，暴露问题

分析上述问题，其中的重点有以下几处：

多板子（开发平台多，第一反应就是要适配（描述混乱的原因之一就是适配导致的））
业务概念统一（什么是业务概念统一呢？举个例子，对于产品而言，在产品需求发布的时候说，当用户点击按钮1时，红灯亮，这就是一个统一的业务概念，因为我们是多板子的开发，我们立马，应该考虑的就是分散性的思考）
不同板子都提供了SDK，但是API并不相同（此处可以这样分析一下，对于定制开发的场景中，特别是这种场景下，需求的实现与否只与板子的供应需求是否相吻合（供应需求就是板子自身对外的开放功能））

通过这三点可以看出，这个需求其实很简单，很清晰，但是对于上述的描述的实现方式，肯定是不行的。

为了好解决问题，我们要引入几个实体板子名称（在开发中，领域模型非常重要，事关需求的成功与否、事关团队的配合度高低），假设目前面对的板子有例如树莓派（Raspberry Pi）、小米开发板、华为开发板。然后还原一下代码

假设工具类名称为ControlBroadUtil, 还原代码如下

这大概就是描述还原的代码，这问题就很清晰了。

硬编码板子类型判断： 目前的实现方式中，通过在业务工具类中硬编码板子类型判断，这会导致代码的脆弱性。一旦有新的板子类型加入，就需要修改代码，可能引入新的错误。
SDK方法名称不一致： 不同板子的SDK提供了相同功能的方法，但方法名称却不同。这种情况可能会导致混乱，使得代码变得难以理解和维护。
紧耦合的业务工具类： 目前的设计中，业务工具类负责判断板子类型并选择相应的SDK。这样的紧耦合设计违反了单一职责原则，使得代码难以测试和扩展。
可维护性差： 随着板子类型的增多，业务工具类会变得越来越庞大，难以维护。任何一次修改都可能引发意外的问题。
扩展性问题： 当需要支持新的板子类型时，目前的设计需要修改现有代码，而不是简单地添加新的板子类型的实现。这降低了系统的可扩展性。
缺乏抽象层： 目前的实现没有明确的抽象层，使得在引入新板子类型时无法简单地使用接口进行统一操作。这违反了面向对象设计的一些原则。
缺乏文档和规范： 由于不同板子类型的方法名称不同，缺乏清晰的文档和规范，团队成员可能难以理解和使用不同板子的SDK。

二、谈谈重构思路，有哪些预留项

面对这类型的问题，其实老手第一眼就想到重构的方式了，我的建议是在给出重构意见时必须考虑后续的问题。

2.1 使用抽象工厂模式（目的就是简化、统一、分离创建流程，使用抽象工厂模式可以满足）

SDK的创建的独立互不影响，对应SDK的配置项都可以在自己的工厂中完成（为什么要用抽象工厂不用简单工厂？因为后续对于一个板子的变化维度可能超过两个（多套API））
可以根据不同的板子进行合理的选择
在特定场景中可以自由切换，比如华为的不同版本板子，在升级之后的切换场景。

2.2 类图结构如下

2.2.1 SDK创建UML

其中：

ControlBoardFactory （抽象工厂）：它声明了一组用于创建一族产品的方法，每个方法对应一种产品，在这里就是每一种板子的SDK。

/**  
*  
* @author: kpa  
* @date: 2024/2/7  
* @description: 它声明了一组用于创建一族产品的方法，每个方法对应一种产品，在这里就是每一种板子的SDK。  
*/  
abstract class ControlBoardFactory<out T : ControlBoardService> {  abstract fun createControlBoard(): T  
}

HuaweiFactory等（具体工厂）：它实现了在抽象工厂中声明的创建产品的方法，生成一组具体产品，这些产品构成了一个产品族，每种产品都位于某个产品等级结构中。

/**  
*  
* @author: kpa  
* @date: 2024/2/7  
* @description:huawei 板子的创建工厂  
*/  
class HuaweiControlBoardFactory : ControlBoardFactory<HuaweiBoardServiceImpl>() {  override fun createControlBoard(): HuaweiBoardServiceImpl {  return HuaweiBoardServiceImpl()  }  
}

ControlBoardService（抽象产品）：它为每种产品声明接口，在抽象产品中声明了产品所具有的业务方法。

/**  
*  
* @author: kpa  
* @date: 2024/2/7  
* @description: 抽象产品，对应业务，为需求接口  
*/  
interface ControlBoardService {  fun switch(switchValue: Int)  
}

HuaweiControlBordImpl等（具体产品）：它定义具体工厂生产的具体产品对象，实现在抽象产品接口中声明的业务方法。

/**  
*  
* @author: kpa  
* @date: 2024/2/7  
* @description:  
*/  
class HuaweiBoardServiceImpl : ControlBoardService {  override fun switch(switchValue: Int) {  TODO("Not yet implemented")  }  
}

2.2.2 SDK API使用UML

对于类中提的提供方接口将使用适配器模式完成与已知SDK API适配，此处设计的目的是：

需求开发中，不需要考虑具体的实现，我们应该做到抽象的需求接口和产品需求是一致的。这样我们即使撤走部分SDK或者添加n中SDK都不会影响我们的业务。
SDK的API我们是不可以介入编程的，所以他在编码体系中只能是直接使用，但是直接使用就会导致代码的耦合性太高，对三方的依赖太强可不是什么好事

所以决定对抽象产品（ControlBoardService）部分使用适配器模式进行设计，要求是：

业务方无感SDK的调用但要调用
业务方可以多组合+自主实现

组合方式：

class HuaweiBoardServiceImpl : ControlBoardService {  private val huaweiBoardSDK: HuaweiBoardSDK by lazy { HuaweiBoardSDK() }  override fun switch(switchValue: Int) {  huaweiBoardSDK.huaweiOpenSwitch(switchValue)  }  
}

2.2.3 外观模式，保持业务掉用的整洁

如果使用上述的代码，在一套体系中还是会出现调用混乱的问题，呐，处理方式就是使用外观模式，右边部分为外观模式下的物理、逻辑结构。

外观模式相对简单。
类图就不画了代码如下：

/**  
*  
* @author: kpa  
* @date: 2024/2/7  
* @description: 外观模式下的工具类  
*/  
object ControlBroadUtil {  private val huaweiBoardFactory: HuaweiControlBoardFactory by lazy { HuaweiControlBoardFactory() }  // 其他工厂  //...  // 需求接口，面相该接口编程  private var controlBoardService: ControlBoardService? = null  /**  * 供应商环境  */  private var supplierEnvironment = ""  private fun init() {  // 统一配置读取  supplierEnvironment = System.getProperty("")  controlBoardService = huaweiBoardFactory.createControlBoard()  }  /**  * 直接使用接口编程  */  public fun getControlBoardService(): ControlBoardService {  return controlBoardService ?: HuaweiControlBoardFactory().createControlBoard()  }  
}