Android RecyclerView 多布局场景下的设计思考：SRP 与 OCP 的权衡与优化

在日常 Android 开发中，RecyclerView 是我们用得非常频繁的一个组件，而与之搭配使用的 Adapter 则承担着数据与视图之间的桥梁作用。本文将围绕 Adapter 的本质角色、多布局场景下是否违反面向对象的设计原则（单一职责原则 SRP 与开闭原则 OCP），以及如何更优雅地应对复杂场景进行系统性梳理。

一、RecyclerView Adapter 的本质：数据 ➜ 视图

Adapter 的职责非常明确：

接收数据源（例如 List）
将每一项数据绑定到一个 View（通过 ViewHolder）
最终展示在 RecyclerView 上

也就是说，Adapter 的核心作用是：将数据转换成视图。

在 Android 中，这种转换通过 onCreateViewHolder() 和 onBindViewHolder() 两个方法实现，前者负责创建 ViewHolder，后者负责数据绑定。

二、ViewHolder 写在 Adapter 里面，违反设计原则吗？

✅ 单一职责原则（SRP）

单一职责原则要求一个类只有一个变化的原因。

ViewHolder 本质上是用于缓存控件引用、绑定数据，如果只是做这两件事，放在 Adapter 中并不会违反 SRP。但如果：

ViewHolder 里写了大量业务逻辑（比如 UI 状态切换、点击事件处理、图片加载等）
Adapter 中判断 item 类型、写复杂的 if-else

就说明一个类承担了过多职责，此时应当考虑拆分。

✅ 开闭原则（OCP）

开闭原则强调：对扩展开放，对修改关闭。

如果你的 Adapter 中存在如下代码：

kotlin 复制代码

when (viewType) {
    0 -> TitleViewHolder(...)
    1 -> ImageViewHolder(...)
    2 -> ContentViewHolder(...)
}

每次新增一个类型都需要修改三处（getItemViewType()、onCreateViewHolder()、onBindViewHolder()），这显然是对修改开放了，违反了 OCP。

三、多布局场景：如何违反 SRP 和 OCP？

在实际开发中，一个 Adapter 往往会处理多种类型的 item，比如：

标题类型
内容类型
图片类型

这时候 Adapter 的代码很可能变成"大杂烩"：

不仅要判断 item 类型
还要写不同 ViewHolder 的构建和绑定逻辑

这时候 Adapter:

不再是简单的"数据与视图桥梁"，职责变得复杂，违反了 SRP。
每新增一个类型都要改动原有逻辑，违反了 OCP。

四、更优雅的设计方案

✅ 1. 使用 AdapterDelegate 模式

定义一个接口：

kotlin 复制代码

interface ItemViewDelegate<T> {
    fun isForViewType(item: T, position: Int): Boolean
    fun getViewHolder(parent: ViewGroup): RecyclerView.ViewHolder
    fun bindViewHolder(holder: RecyclerView.ViewHolder, item: T)
}

假设我们有三种类型的数据：

kotlin 复制代码

sealed class ListItem {
    data class Title(val text: String) : ListItem()
    data class Content(val description: String) : ListItem()
    data class Image(val url: String) : ListItem()
}

编写三个 Delegate：

1. TitleDelegate.kt

kotlin 复制代码

class TitleDelegate : ItemViewDelegate<ListItem> {
    override fun isForViewType(item: ListItem, position: Int): Boolean {
        return item is ListItem.Title
    }

    override fun onCreateViewHolder(parent: ViewGroup): RecyclerView.ViewHolder {
        val view = LayoutInflater.from(parent.context).inflate(R.layout.item_title, parent, false)
        return TitleViewHolder(view)
    }

    override fun onBindViewHolder(holder: RecyclerView.ViewHolder, item: ListItem, position: Int) {
        val title = item as ListItem.Title
        (holder as TitleViewHolder).bind(title)
    }

    class TitleViewHolder(itemView: View) : RecyclerView.ViewHolder(itemView) {
        fun bind(data: ListItem.Title) {
            itemView.findViewById<TextView>(R.id.tvTitle).text = data.text
        }
    }
}

其他的 ContentDelegate 和 ImageDelegate 与其类似，只需修改数据类型和视图绑定部分。

编写通用 Adapter：

kotlin 复制代码

class MultiTypeAdapter(
    private val items: List<ListItem>,
    private val delegates: List<ItemViewDelegate<ListItem>>
) : RecyclerView.Adapter<RecyclerView.ViewHolder>() {

    override fun getItemViewType(position: Int): Int {
        val item = items[position]
        return delegates.indexOfFirst { it.isForViewType(item, position) }
    }

    override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): RecyclerView.ViewHolder {
        return delegates[viewType].onCreateViewHolder(parent)
    }

    override fun onBindViewHolder(holder: RecyclerView.ViewHolder, position: Int) {
        val item = items[position]
        val delegate = delegates[getItemViewType(position)]
        delegate.onBindViewHolder(holder, item, position)
    }

    override fun getItemCount(): Int = items.size
}

✅ 2. 使用抽象基类 + 多子类

kotlin 复制代码

abstract class BaseItem {
    abstract fun getType(): Int
}
class TitleItem : BaseItem()
class ContentItem : BaseItem()

通过数据类本身带有类型信息，让 Adapter 更加清晰。

✅ 3. 使用 DataBinding 或 Jetpack Compose

数据绑定与 Compose 的声明式 UI 特性能够将视图逻辑从 Adapter 中进一步抽离，让每种类型的视图绑定与逻辑都分散在更合适的位置。

五、总结

问题	多布局下是否违反	原因
单一职责原则（SRP）	✅ 会	Adapter 担起了创建、判断、绑定等多重职责
开闭原则（OCP）	✅ 会	每新增一个类型都要改原有逻辑
如何优化	✅ 使用 AdapterDelegate、抽象类、DataBinding 等方式

当项目越来越复杂时，合理抽象、拆分职责，不仅能提升代码可维护性，也能让我们更从容地面对未来的需求变更。