首先，组合并不总是比继承更受欢迎，两者都有各自最适合的场景。
试着起草你将如何实现这两个，并比较他们。
例如，如果使用继承，则可以使用BaseFragment执行此操作，而如果使用继承，则可以执行以下操作：

class SingleFragment {
    // feature A specific code, could be abstracted to a separate class
    // feature B specific code, could be abstracted to a separate class
}

这取决于你去找出哪一个适合你的目的，但根据我的经验，继承在这种情况下会有以下好处：
1.更少的混乱代码。虽然片段A和B的代码都在SingleFragment中使用，但此片段变得更复杂，更难维护。这也违反了开-闭原则（假设A和B没有密切关系）。
1.当其中一个改变时，重构更容易。即使其中两个现在共享相似的布局，但其中一个将来可能会改变。替换BaseFragment将比从SingleFragment中取出特性A的所有代码更容易，也更不容易出错。

这里有一些误解。是的，组合比继承更受欢迎，但这并不意味着你应该不惜一切代价避免继承。它是语言的一个基本部分，因此不应该被忽视。
Composition Over Inheritance背后的基本思想是，继承到多个级别会使代码更难理解，因为逻辑可能会扩展到多个父类中，可能会导致更改您不希望更改的行为，然后可能会向用户公开许多接口和方法，使代码更难编写和调试。因为你不是有5个方法可供选择，而是有50个方法可供选择，这些方法来自所有父类。每次你需要一些方法时，你就扩展一个类，得到整整50个方法，而这些方法是你不想要、不需要、也不应该使用的。
组合消除了这一点，允许更小、更简单、更容易阅读的类。让你重用你需要的代码部分，并且仅仅是这样。
读一下用例模式，当你写一堆业务逻辑类，每个类只有公共方法，只做一件事情！然后你构建片段等等，只使用你需要的用例（逻辑片段）。
也就是说，FragmentA和FragmentB无论如何都将从默认Fragment类继承！
我认为，与您的一般想法相反，您应该始终从一些BaseAbstractFragment开始：Fragment（），你的片段A和B将从它继承，因为你迟早会遇到复制片段中的代码的需要。
例如，它们都将保存适配器字段，可能是一些需要在生命周期中清除的可观察项或回调等。您可以在基本片段中完成所有这些操作，然后仅在片段A或B中指定其余部分。
为什么您需要2个不同的适配器用于相同布局的片段？
1.你可以有一个适配器，它接受一个函数作为参数，因为在每个片段中不同的适配器构造上传递这个函数，这里有一个适配器中的字段.
瓦尔单击操作：（项目：UIMODEL，位置：整数）-〉单位，
这就是你所说的，这里我用presenter，但想法是一样的，在构造器中传递一个动作。

init {
    adapter = GenericAdapter(
        data = items,
        presenter = SinglePickPresenter(clickAction = { item, _ -> callback.invoke(item) })
    )
}

这样，您可以在每次创建适配器时更改回调