前言：

很多架构在项目初的时候看不出破绽；只有当项目维护和扩展越来越难的时候，才真正意识到—— 设计模式不是“装饰”，而是“地基” 。

背景起点：一个日常刷新操作的尴尬实现

abstract class BaseCustomView : View {  
 
    constructor(context: Context) : super(context)  
    constructor(context: Context, attrs: AttributeSet?) : super(context, attrs)  
      
    protected abstract fun onRefreshView()  
}

❗问题显现：灵活性的代价是“失控”

子类实现onRefreshViwe的具体业务逻辑，表面看这没有问题，但随着项目复杂度提升，我发现：

• 想要在刷新时加个节流逻辑或埋点日志，无处下手；
• 子类多了之后，每个子类都要手动调用通用逻辑，非常容易遗漏；
• 所有子类行为无法被基类掌控，流程难以统一。

深层剖析：违反了哪些设计原则？

这样的设计，很明显违背了设计模式中的若干设计原则

从单一职责原则触发，即：

• onRefreshViwe() 既承担了“触发刷新逻辑”的职责，又承担了“执行刷新内容”的职责；
• 结果导致：无法单独插入通用逻辑，也无法明确区分“框架控制流程”和“具体视图变化”；
• 日后代码越来越多，难以维护、测试、复用。

从开闭原则出发，即：

• 如果想增加通用刷新逻辑（比如打点、节流、动画），只能：

1. 修改所有子类 onRefreshViwe()；

2. 或者要求外部每次调用 onRefreshViwe() 前都记得手动调用某个逻辑；
• 这相当于每次“扩展”都需要“修改”已有逻辑，违反了开闭原则。

从控制反转确实出发，即

• onRefreshViwe() 由子类和调用方直接控制，基类失去了调度权；
• 想在不破坏现有代码的前提下“统一的流程”，几乎不可能；
• 外部代码直接操作了本该由框架控制的生命周期，导致后期可插拔、扩展困难。

✅ 解决之道：模板方法模式的回归

abstract class BaseCustomView : View {
    constructor(context: Context) : super(context)
    constructor(context: Context, attrs: AttributeSet?) : super(context, attrs)
    /**
     * 外部调用的统一入口，包含基础逻辑
     */
    final fun refreshView() {
        // 基类统一逻辑
        invalidate() // 或其他通用刷新逻辑
        // 调用子类的实际逻辑
        onRefreshView()
    }
    /**
     * 子类重写这个方法，而不是原来的 onRefreshView()
     */
    protected abstract fun onRefreshView()
}

优化后方案统一入口，控制权回归基类，子类只关注差异逻辑，提升维护性与可控性。

设计让流程控制权下放给了子类和外部，牺牲了封装性和扩展性，导致架构可控性差、通用逻辑难以集中、维护代价高。

这其实是一个很小的项目架构的问题，在日常的工作会出现无数的这样的问题，解决方法也不只是我说的那样，如果不嫌麻烦，单独处理所有子类也是一种处理的技术手段，技术手段服务于项目这没毛病，只是更好的架构能节省更多的时间和精力。

为什么设计模式“知道却用不上”？

设计模式在初期看起来“多余”

• 项目刚开始、逻辑简单，直接写 if、new 这些快速完成需求就好。
• 工期紧、团队初始，复杂结构反而让人觉得“多此一举”。

但问题是，不是设计模式太复杂，而是项目现在太简单 —— 一旦复杂度上来，设计失控的代价就暴露了。 写起来“方便”的做法，往往是“技术债”起点

• 直接 override 方法、直接调用子类方法，省了写接口、抽象类、模板方法；
• 但这些方便背后的成本是：缺乏抽象、耦合加深、流程不可控； 日后需求变更或新增功能时，才发现所有逻辑“黏”在一起，动一个地方就像抽积木。

类似场景下的设计模式选型参考

结语：项目在成长，架构必须进化

设计模式不是“高级标签”，而是降低维护成本、统一团队协作的结构基础。

附：设计模式六大原则简表