在我想的示例中，我有大约 4 行代码可以被一个函数封装，并且这个函数肯定会在同一层次结构中的其他类中使用。
我有以下选项可重用该代码：
我绝对不会做 1 或 4。我过去会做 2，但我试图保持组合优于继承的原则，所以我倾向于 4，但对于最有可能的事情来说似乎很多永远不会在层次结构之外使用，并且只有 4 行。我知道这很挑剔，但我想找出正确的方法。
继承是有原因的。它被过度使用的事实并不意味着它没有合法用途。关键是你是否使用它不应该取决于你是否可以轻松地重用它，而是基于你的基类代表什么，它属于基类是否有意义。
如果没有更好地了解您的类是什么，以及您尝试重用的方法是什么，我无法针对您的特定情况给出具体建议。但是这样想：当你说它“很可能永远不会在层次结构之外使用”时，是因为它纯粹只是在层次结构之外没有意义吗？或者只是你不认为有人会构建碰巧使用此功能的东西，即使它可以想象在层次结构之外有意义？
如果这种方法在您正在谈论的特定层次结构之外有任何意义，我会建议方法＃3。
当然，所有这些都假设你的类层次结构首先是一个层次结构。另一个常见的继承滥用是人们在应用程序的上下文中对不需要分层的对象强制使用层次结构。
我同意组合是比一般继承更好的选择。但是用一些逻辑组合你的对象，也许是通过策略模式，与多个类重用相同的代码是一个不同的问题。
如果那些需要这个功能的类都具有相同的基类，那么将它放在基类中是有意义的。这不像子类需要知道基类的内部工作来进行这个调用。
如果各种子类需要不同版本的代码，那么通过策略模式（使用组合）创建行为是可行的方法。但我假设相同的代码满足每个子类。
我不会做#4，因为那样该代码可用于其他没有业务调用它的类。如果代码在基类中，那么您可以将其设置为受保护的，因此仅对需要它的类可用。
如果此类函数参数将成为类的字段，则它旨在对您的类状态进行操作，因此应该是解决此类操作的基类的成员。
如果您对一些在层次结构之外或从层次结构的多个分支有意义的数据进行操作，并且参数的含义不受对象状态的约束，则使其成为实用程序类中的函数。
如果它与您的类层次结构特别相关，请使用基类。如果没有，请使用选项 4。这里不需要合成。