Oop 用两个方法创建一个小类，只用于继承，这是一个糟糕的设计吗？

我想创建一个包含两个方法的类，除了创建继承方法的两个子类之外没有其他用途。此类无法自行运行。这是一个坏的编程设计还是习惯？

这是一个好习惯，它会导致更好的函数组织。另一个原因是您只需查看继承树，就知道它与两个函数类相关。它没有什么害处。

甚至有些类除了让其他类从中派生之外什么都不做。超类本身是否有有用的实例并不重要。仅为其他类派生而存在的类通常称为抽象类；有些语言，如C++，也有语法特征，允许编译器在试图从抽象类创建对象时提供错误。所以有这样的课也不会那么糟糕

除此之外，什么是“坏习惯”？如果设置使代码更容易理解，那么它就不会坏

当然，如果您打算派生的两个类实际上没有任何共同点，而这两个方法只是“嘿，我注意到该类中的10行代码与另一个类中的10行代码相同”，那么将其转换为一个公共超类可能会带来更多的混乱。类仍然应该有某种形式的关系。如果只是为了共享一些随机出现的代码，那么独立函数可能是更好的选择

基本上，看看类的名称。如果你的新超类被命名为“一些非常通用的名字，因为我不知道它是什么”，那么它可能不是“好的设计”。另一方面，如果您对超类有一个合适的名称，并且派生类的名称仍然与超类有“某种”关系，那么这可能不是一件坏事

另一个“好”的强烈暗示是，当你开始使用指向超类的指针时，因为你不在乎你是在处理一个子类还是另一个子类

总的来说，没有内在的好或坏。这在很大程度上取决于具体情况。但是，一般来说，您应该始终尝试遵循面向对象的原则。例如，无论何时创建一个类，无论是抽象的还是具体的，该类都应该同时具有数据和行为。这条规则非常重要，它一直是面向对象的基础。没有数据的类只是一堆方法（这是过程编程，不是OO）。没有行为的类是一堆变量（同样是过程性的，不是OO）。因此，将数据和行为结合在一起非常重要。但是，它们之间应该有逻辑关系，而不是随意地放在一起。例如，方法应该以某种方式访问数据

当然，这条规则也有偏差。例如，在静态类中可能只有一组方法（如Java中的Math类），或者在接口中可能只有一组常量。但是，它们是例外而不是规则。他们在那里，出于必要，是为了方便。它们不是严格面向对象意义上的真正类

因此，始终以正确的原则为目标，只有当没有其他方法来实现它时才偏离，而且只是作为例外，而不是作为规则

前一点是指如何构造类。同样，为了设计类之间的关系，应该遵循逻辑路径。仔细思考您正在处理的每个概念，看看每个概念作为一个类是否有意义，然后看看这些类之间的关系。如果你有三个可以在继承中组织的概念——两个从父类派生的类，那么就这样吧。如果父类有两个方法，则为ok。即使它有一个方法，它仍然是好的。只要它代表一个连贯的逻辑单元

---

好帖子！我稍后会投票表决这个答案。我不能确定它们是否相关，但它们相互依赖。我也想过把这两个班合并成一个班。我有一个类，它显示从属性列表加载的一系列文本。然后，另一个类显示特定的精灵/图片，该精灵/图片也从与正在显示的文本对应的属性列表加载。这两个类都有两个方法：loadValueFromPlist和displayNextValue。在loadValueFromPlist内部是didPlistLoad，它在完成后执行一些操作。我想创建一个包含这些方法的Supercals。很抱歉，我已经达到了最大文本限制。我想将超类命名为“PropertyLoader”，它包含前面列出的三个方法。这两个类继承了这一点，并将重写didPlistLoad以执行某些特定操作。所有其他方法保持不变。感谢你的回答。为了澄清Christian Stiebers的帖子：不要用继承来保存代码行。那是个糟糕的设计。这些类应该有一种“类”关系。您的“PropertyLoader”“TextLoader”/“ImageLoader”示例似乎没有问题（imho）。我决定不创建此类，而是更改类似的方法，使其功能不同。我将投票表决这个答案，因为它回答了我原来的问题。提问那些说“这属于”的人总是很重要的，因为他们经常是错的。还有，抽象类。调查一下。