2

I have two classes (named MyFoo1 and MyFoo2) that share some common functionality. So far, it does not seem like I need any polymorphic inheritance 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, the MyFoo1 and MyFoo2 classes will derive from that abstract class.

Any suggestion on what would be the best design decision?

|improve this question
  • 1
    @DanielA.White - Programmers is for questions about the field, etc. Architectural questions still belong on StackOverflow. – Justin Niessner Nov 22 '11 at 16:28
  • The reason you are getting vague answers is because you have obfuscated what Foo1 and Foo2 are in your question. i.e. it is not clear whether they are specialisations of the same thing. Can you tell us more about them? – Fenton Nov 22 '11 at 16:59
  • @Sohnee: I realized that also but I think I have got my answer from Justin. Thanks for your help as well – palm snow Nov 22 '11 at 19:29
  • 3
    @JustinNiessner Please check the FAQ before giving incorrect advice. Software architecture is indeed considered on-topic on Programmers.SE. – S.Robins Feb 1 '12 at 3:59
  • @S.Robins - But it also valid on StackOverflow where the question was asked and seems a better fit for architecture style questions. This is one of the downsides to having overlap between the two. – Justin Niessner Feb 1 '12 at 14:16
14

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.

|improve this answer
  • Each of these two classes interface with a third party library to fulfill a unique functionality. In some cases they use third party library in same way; in other each of it has own way of calling and processing response from same third party library. – palm snow Nov 22 '11 at 16:30
  • 3
    If that's the case, then I would wrap the 3rd party library in a utility class or interface and provide the common functionality to the classes that way. This allows you to change out 3rd party libraries and enforce the boundary between the external dependency and your code. – Mark J Miller Nov 22 '11 at 16:49
  • That's it. In the end the question when doing a design decision should always be, "What will be easier to read?" (or "What would another person find easier to understans?" if you want) – Konamiman May 27 '14 at 10:53
3

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.

|improve this answer
1

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.

|improve this answer
0

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.

|improve this answer
0

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.

|improve this answer
  • but what about class Tomato extends Fruit { //... oh no all my properties are like vegetables. } – s_hewitt Jan 31 '12 at 20:46
0

Make sure your design is such that each class has clear responsibilities which can clearly be described by their names. Consider which modularization will produce code that is easiest to test and modify. Factoring out whatever common code to a class called Utilities is a code smell.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.