Question

I’m working on a legacy Java application, that deals with “fruits” and “vegetables”, let’s say, for the sake of the question.
They are treated as different things internally, cause they don’t have all methods/properties in common, but a lot of things are DONE very similar to both of them.

So, we have a ton of methods doSomethingWithAFruit(Fruit f) and doSomethingWithAVegetable(Veg v), that use the proper doOtherStuffWithAFruit(Fruit f) / doOtherStuffWithAVeg(Veg v). And those are very similar, except that methods that do things with fruits only call the methods that do things with fruits, and the same thing for vegetables.

I want to refactor this to reduce the duplication, but I’m not sure what is the best way to accomplish that. I’ve read a bit about some design patterns, but I don’t know if it has made any clearer to me. (I can recognize some patterns in the code I use, but I don’t really know when I should be applying a pattern to improve things around. Maybe I should be reading more about refactoring itself…)

I was thinking of these two options:

1. Creating a class that can have an instance of either a Fruit or a Vegetable and pass it around to the methods, trying to minimize the duplication. It would go like this:

public void doSomething(Plant p) {
   // do the stuff that is  common, and then...
   if (p.hasFruit()) {
       doThingWithFruit(p.getFruit());
   } else {
       doThingWithVegetable(p.getVegetable());
   }
}

This would get things a bit better, but I don’t know… it still feels wrong.

2. The other alternative I thought was to put an interface in Fruit and Vegetable with the stuff that is common to them, and use that to pass it around. I feel this is the cleaner approach, although I will have to use instanceof and cast to Fruit/Vegetable when it needs stuff that is specific to them.

So, what more can I do here? And what are the shortcomings of these approaches?

UPDATE: Note that the question is a bit simplified, I’m looking for way to do things WITH the “plants”, that is, code that mostly “uses” them instead of doing things TO them. Having said that, those similar methods I refer to cannot be inside the “Plants” classes, and they usually have another argument, like:

public void createSomethingUsingFruit(Something s, Fruit f);
public void createSomethingUsingVegetable(Something s, Vegetable v);

Namely, those methods have other concerns besides Fruits/Vegetables, and aren’t really appropriated to be in any Fruit/Vegetable class.

UPDATE 2: Most code in those methods only reads state from the Fruit/Vegetable objects, and create instances of other classes according to the appropriate type, store in the database and so on — from my answer to a question in the comments that I think it’s important.

Answer 1

Another option you can use, or perhaps include it as part of your solution, is to ask the consumer if it can manage the object that you are passing it. At this point, it becomes the consumer’s responsibility to ensure it knows how to handle the object you are sending it.

For instance, if your consumer is called Eat, you would do something like:

Consumer e = new Eat();
Consumer w = new Water();
if( e.canProcess( myFruit ) )
   e.doSomethingWith( myFruit );
else if ( w.canProcess( myFruit ) )
   w.doSomethingWith( myFruit );

.... etc

But then you end up with a lot of it/else classes, so you create yourself a Factory which determines which consumer you want. Your Factory basically does the if/else branching to determine which consumer can handle the object you pass, and returns the consumer to you.

So it looks something like

public class Factory {
   public static Consumer getConsumer( Object o ){
    Consumer e = new Eat();
    Consumer w = new Water();
    if( e.canProcess( o ) )
       return e;
    else if ( w.canProcess( o ) )
       return w;
   }
}

Then your code becomes:

Consumer c = Factory.getConsumer( myFruit );
c.doSomethingWith( myFruit );

Of course in the canProcess method of the consumer, it would be basically an instanceof or some other function your derive to determine if it can handle your class.

public class Eat implements Consumer{
   public boolean canProcess(Object o ){
     return o instanceof Fruit;
   }
}

So you end up shifting the responsibility from your class to a Factory class to determine which objects can be handled. The trick, of course, is that all Consumers must implement a common interface.

I realize that my pseudo-code is very basic, but it is just to point out the general idea. This may or may not work in your case and/or become overkill depending on how your classes are structured, but if well designed, can significantly improve readability of your code, and truely keep all logic for each type self-contained in their own class without instanceof and if/then scattered everywhere.