Refactoring Multi‑Board SDK Integration Using Abstract Factory, Adapter, and Facade Patterns

The author receives a refactoring request for a product that must run on various custom Android boards, each providing its own SDK with differently named methods for the same operation (e.g., opening a switch). The current implementation uses a utility class that hard‑codes board type checks and directly calls the vendor‑specific APIs, leading to fragile, tightly‑coupled code.

Key problems identified include hard‑coded board type discrimination, inconsistent SDK method names, violation of the Single Responsibility Principle, poor maintainability, limited extensibility, lack of an abstraction layer, and insufficient documentation.

To address these issues, the author recommends introducing an Abstract Factory pattern to encapsulate SDK creation, allowing each board type to have its own factory while presenting a uniform interface to the business layer.

Class diagram and Kotlin code examples: /** * @author kpa * @date 2024/2/7 * @description Abstract factory for creating a family of board SDK services */ abstract class ControlBoardFactory { abstract fun createControlBoard(): T } /** * @author kpa * @date 2024/2/7 * @description Concrete factory for Huawei boards */ class HuaweiControlBoardFactory : ControlBoardFactory () { override fun createControlBoard(): HuaweiBoardServiceImpl { return HuaweiBoardServiceImpl() } } /** * @author kpa * @date 2024/2/7 * @description Abstract product representing board operations */ interface ControlBoardService { fun switch(switchValue: Int) } /** * @author kpa * @date 2024/2/7 */ class HuaweiBoardServiceImpl : ControlBoardService { override fun switch(switchValue: Int) { // TODO: implement Huawei SDK call } }

For the SDK API differences, an Adapter pattern is applied so that the business code interacts with a unified interface while the adapters translate calls to the specific vendor SDK methods, keeping the business layer unaware of the underlying implementations.

A Facade (ControlBroadUtil) is introduced to provide a clean entry point for the rest of the application, lazily initializing the appropriate factory and exposing a single method to obtain the ControlBoardService instance.

Result analysis shows that the refactor yields loose coupling, improved extensibility (adding a new board only requires a new factory and product), a unified business concept, and easier testing and maintenance, while also emphasizing the importance of documentation and coding standards.