网站建设界面建议,共享vps可以做网站吗,seo服务外包报价,社区网站做的比较好的有哪些theme: cyanosis
月黑风高#xff0c;好兄弟发给我一个重构需求#xff0c;咨询我的意见。
一、 场景分析 开发的产品是需要运行到不同的定制Android板子#xff0c;不同板子有对应的不同SDK提供的API#xff0c;目前的业务端#xff0c;业务流程基本是确定的#xff0…
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 ControlBoardFactoryout T : ControlBoardService { abstract fun createControlBoard(): T
}HuaweiFactory等具体工厂它实现了在抽象工厂中声明的创建产品的方法生成一组具体产品这些产品构成了一个产品族每种产品都位于某个产品等级结构中。
/**
*
* author: kpa
* date: 2024/2/7
* description:huawei 板子的创建工厂
*/
class HuaweiControlBoardFactory : ControlBoardFactoryHuaweiBoardServiceImpl() { 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() }
}
三、重构结果分析
经过以上的分析和重构思路可以得出以下重构结果分析
3.1 抽象工厂模式的优点
松耦合 抽象工厂模式将产品的创建与使用分离使得系统更加灵活减少了模块间的直接依赖达到松耦合的效果。可扩展性 当需要增加新的板子类型时只需添加新的具体工厂和产品类无需修改已有代码符合开闭原则提高了系统的可扩展性。统一接口 抽象工厂模式提供了一组统一的接口使得客户端无需关心不同板子的具体实现细节从而简化了客户端代码。业务概念统一 通过抽象工厂模式可以将不同板子的SDK统一到一组接口中使得业务概念更加清晰和统一。
3.2 适配器模式的优点
解耦 适配器模式将业务代码与SDK的具体实现解耦业务方无需关心底层SDK的细节提高了代码的可维护性和可读性。灵活性 适配器模式使得业务方可以更灵活地选择和切换不同的SDK而无需修改业务代码降低了对SDK的依赖性。可扩展性 当需要添加新的SDK时只需实现适配器接口即可无需修改已有代码符合开闭原则提高了系统的可扩展性。
四、总结
通过对现有代码的分析和重构我们解决了原有代码存在的问题提高了系统的可维护性、可扩展性和可读性。使用抽象工厂模式和适配器模式使得系统更加灵活业务概念更加统一业务代码与底层SDK的实现解耦。这样的设计不仅适应了当前的业务需求还为未来的扩展和变化提供了良好的支持。
在实际开发中重构是一个不断演进的过程需要根据实际情况灵活运用设计模式和原则不断优化和改进代码结构。同时良好的文档和规范也是团队协作的重要保障能够使团队成员更加容易理解和使用不同板子的SDK。
