What is the better design decision approach?

Question

I have two classes (MyFoo1 and MyFoo2) that share some common functionality. So far it does not seem like I need any polymorphic inheritence but at this point I am considering the following options:

1. Have the common functionality in a utility class. Both of these classes call these methods from that utility class.
2. Have an abstract class and implement common methods in that abstract class. Then derive MyFoo1 and MyFoo2 from that abstract class.

Any suggestion on what would be a better design decision?

Answer 1

Are Foo1 and Foo2 actually related (conceptually, that is) or do they simply share some functionality?

If they're conceptually related, I would go with an abstract class.

If they simply share the functionality, I would break out that functionality and make a separate class. You can then use composition to build Foo1 and Foo2.

Answer 2

As always it depends.

If all instaces of Foo1 and Foo2 can logically be called FooParent then use inheritance.

For the utility class to make sense it should be something that be used across multiple projects, think about the Apache libraries on this one.

Typically in these scenarios you want to have Foo1 and Foo2 be composed of FooUtility.

Answer 3

As the other posters stated it is difficult to answer the question without knowing the relationship between the classes. The answer is, as always, it depends.

Inheritance should really only be used if you can say "Foo1 is a FooParent". Inheritance is a powerful tool, but it can also tie your hands down the road.

The GoF recommended "composition over inheritance" - using interfaces allows for maximum flexibility. The downside is that you can end up with code bloat if you declare an interface for every little responsibility. Interfaces generally describe what an object does instead of what it is (inheritance).

Theory aside, is the common functionality key to what Foo1 and Foo2 are or do? Or is it more boilerplate code that you'd like to not have to write every time. If it is part of the class behavior, use inheritance. If not, if it's just boilerplate (data access code, validation or security) then a utility class would probably be my choice.

Answer 4

From your question I feel that the two classes Foo1 and Foo2 have no business relationship(because you have specified that you do not need any polymorphic inheritance).

so based on that I would suggest you to use some external Utility class rather than adding an abstract super class. Since relating two classes which are not really related just to share common functionality could compromise/complicate the future expansions of your project.

For example if you have some Foo11 and Foo12 which has business relationship to Foo1 it would be simpler and more logical to use common parent Foo1Parent at that point.

Answer 5

As you said --

... that share some common functionality. So far it does not seem like I need any polymorphic inheritance ...

Which means that, you can encapsulate the common functionality. From my experience, most of the time, encapsulation is better than inheritance.

class Myclass{
   private Common common;

}

I am not saying Inheritance is bad. It has its own place.