Base class defines many protected methods: Is it a good OOP design?

I wrote a base class which defined many protected methods. Those methods are called in its sub classes. The methods define basic operations for its sub classes. For instance:

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();
   }
}

I am just wondering if it is a good OOP design? Read the source, we know Sub1 doesn't need Base.bar() at all, Sub2 doe开发者_C百科sn't need Base.foo() at all. It's sort of redundant I think. But I don't know better solution, anyone could give some advice? Thanks!

Generally you should avoid these kind of object dependencies in your design. If the functionality of foo() and bar() doesn't change in derived classes, you might want to put it in an outer class and use that one instead:

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();
     ...
   }
}

This foo & bar example does not look well. Your problem might be a bad assignment of responsibility to the objects or misuse of inheritance. Posting the real code would help to write better answers.

Apologies, but you're thinking about this the wrong way. The question isn't "Should sub2 inherit base, it doesn't need that method"

The question should be "Is sub2 a Base" e.g Is frog an Animal? Yes, frog can inherit Animal, but frog should not inherit Mammal.

If sub2 is a base, you're on the right track, if base is just a collection of functions that may be useful, then something is wrong.

My thoughts

1- If your designing for the first time, try to follow Principle of Dependecy injection as i can clearly see that you are creating objects Helper1 , Helper2 in different sub classes and may be duplicating code also.

2- I would suggest that Create Helper1 and Helper 2 as properties in your base class if you don't need different instances of helper1 and helper 2 or posibly make them Virtual so that you can overrite them if needed.

3- you are writing directly to the implementation and your client code is directly depends upon the concrete classes use Interfaces , it will make your classes more testable.

4- AND HERE IS THE GOLDEN RULE : If the problem you are dealing is not so much complicated and you don't see a reason for changing them in near future than coninue using what you are doing , DON'T MAKE YOUR LIFE COMPLICATED.

ALL good oop progrmming is good but if you see a better and simpler solution than implement simpler one becoz for using ABSTRACTION you pay the price of complexity.

one more important rule : See if you eaisly test your class design without making changes in your design than your design is on right track.

I see that's a Interface segregation Principle issue one of SOLID rules.

if your subClasses dosen't need all base class function you may split the base class to more specific base classes or interfaces