基类定义了许多受保护的方法：这是一个好的OOP设计吗？

Question

我编写了一个基类，它定义了许多受保护的方法。这些方法在其子类中调用。 这些方法定义了其子类的基本操作。 例如：

class Base{
   protected void foo(){}
   protected void bar(){}
}

class Sub1 extends Base{//The sub class only needs Base.foo()
   public void po(){
     ...
     foo();
     ...
   }
}

class Sub2 extends Base{//The sub class only needs Base.bar()
   public void ko(){
     ...
     bar();
     ...
   }
}

class Sub3 extends Base{//The sub class needs both Base.bar() and Base.foo()
   public void lo(){
     ...
     bar();
     ...
     foo();
   }
}

我只是想知道这是否是一个好的OOP设计？阅读源代码，我们知道 Sub1 根本不需要 Base.bar()，Sub2 不需要 Base。 foo() 根本就没有。我认为这有点多余。但我不知道更好的解决方案，有人可以给一些建议吗？谢谢！

Answer 1

一般来说，您应该在设计中避免此类对象依赖性。如果 foo() 和 bar() 的功能在派生类中没有改变，您可能希望将其放入外部类中并使用该外部类

class Base{

}

class Helper1  {
   public void foo(){}
}

class Helper2  {
   public void bar(){}
}

class Sub1 extends Base{
   private Helper1 a = new Helper1();
   private Helper2 b = new Helper2();

   public void po(){
     ...
     a.foo();
     ...
     b.bar();
   }
}

class Sub2 extends Base{
   private Helper2 b = new Helper2();

   public void ko(){
     ...
     b.bar();
     ...
   }
}

：酒吧的例子看起来不太好。您的问题可能是对对象的责任分配不当或继承的误用。发布真实的代码将有助于编写更好的答案。

Answer 2

抱歉，但你思考这个问题的方式是错误的。问题不是“sub2 应该继承 base，它不需要那个方法”

问题应该是“sub2 是 Base 吗”，例如青蛙是动物吗？是的，青蛙可以继承 Animal，但青蛙不应该继承 Mammal。

如果 sub2 是一个基础，那么你就走在正确的轨道上，如果基础只是可能有用的函数的集合，那么就有问题了。

Answer 3

我的想法

1-如果您是第一次设计，请尝试遵循依赖注入原则，因为我可以清楚地看到您正在不同的子类中创建对象 Helper1 、 Helper2 并且也可能重复代码。

2-如果您不需要 helper1 和 helper 2 的不同实例，我建议在您的基类中创建 Helper1 和 Helper 2 作为属性，或者可能将它们设为虚拟，以便您可以在需要时覆盖它们。

3-您直接编写实现，并且您的客户端代码直接依赖于使用 Interfaces 的具体类，这将使您的类更具可测试性。

4-这是黄金法则：如果你正在处理的问题不是那么复杂，并且你看不到在不久的将来改变它们的理由，而不是继续使用你正在做的事情，那就不要让你的生活变得复杂。

所有好的 oop 编程都是好的，但是如果你看到一个比实现更简单的解决方案更好、更简单的解决方案，因为使用抽象，你就付出了复杂性的代价。

还有一个更重要的规则：看看您是否可以在不更改设计的情况下轻松测试您的类设计，而不是让您的设计步入正轨。

Answer 4

我发现这是 SOLID 规则之一接口隔离原则问题。

如果您的子类不需要所有基类函数，您可以将基类拆分为更具体的基类或接口