What is the right way to use polymorphism and inheritance in C++ to handle a basket of fruit? - c++

Question

Say I'm coding a robot that processes a basket of fruit. Oranges need to be juiced, apples need to be sliced, and bananas need to be peeled. Fortunately, our robot has the exact tools needed for juicing, slicing, and peeling.
Robot::processFruit(List<Fruit*> basket)
{
foreach(Fruit *fruit, basket)
{
if( ? ) { juiceIt(fruit); }
else if( ? ) { sliceIt(fruit); }
else if( ? ) { peelIt(fruit); }
}
}
This is a generic example of a problem that I am occasionally confronted with. I have a gut feeling that there is something wrong in my design such that I am even led to a processFruit() function, as I'm using an object oriented language, but it doesn't appear to have a clean solution to this problem.
I could create an enum FruitType { Orange, Apple, Banana} then require each fruit to implement virtual FruitType fruitType(), but then it seems I'm just re-implementing a type system.
Or I could have functions virtual bool isOrange(); virtual bool isApple(); ... but as we can see that would get out of hand very quickly.
I could also use C++'s typeid, but this wikibook says
RTTI should only be used sparingly in C++ programs.
So I am reluctant to take that approach.
It seems that I must be missing something fundamental and crucial in the design of an object oriented program. C++ is all about inheritance and polymorphism, so is there a better way to approach this problem?
Update: I like the idea of having a generic process() function that all Fruit are required to implement. But what if I now want to add a Lemon and want to juice that? I don't want to duplicate the juicing code, so should I create a class Juicable : public Fruit and have Oranges and Lemons both be Juicable?

Answer 1

See Tell, don't ask:
Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp
You want to define a base Fruit class, which has a virtual process method. Apples, oranges and bananas would each implement their own version of process which does the correct thing for that type of fruit. All your robot needs to do is pull the next Fruit* out of the basket, and call process on it:
Robot::processFruit(List<Fruit*> basket)
{
foreach(Fruit *fruit, basket)
fruit->process();
}
The kind of if/else/else handling you're doing in your code example is exactly the kind of thing that polymorphism is meant to avoid, and it's definitely not doing this the "OOP" way.

Answer 2

The way I would handle this situation is to create a superclass called Fruit with a pure virtual method called process(). Orange, Apple and Banana will all superclass fruit, and each of them will provide an implementation of process() which takes the appropriate action for that particular type (i.e., subclass) of fruit.
So your loop would look more like:
Robot::processFruit(List<Fruit *> basket)
{
foreach(Fruit *fruit : basket)
{
fruit->process();
}
}
Otherwise, Robot's function would basically need a way to determine the type of fruit it's dealing with. Typically when I need to do this, I simply try to dynamic_cast<>() the Fruit pointer to whatever other type it might be. For instance, suppose I have a Fruit * to an object that is a Banana. I would take advantage of the following:
Fruit *f = new Banana();
Orange *o = dynamic_cast<Orange *>(f); // o is NULL, since f is NOT an Orange.
Banana *b = dynamic_cast<Banana *>(f); // b points to the same object as f now.
However, the first solution is, in my opinion, far cleaner and more respectful of object oriented programming. The second solution is sometimes useful, but should be used sparingly.
Update: If you really want the Robot to do the processing code, then I would suggest, instead of having the Robot call process(), have your robot class implement the processing methods, and then have the fruit itself take advantage of the robot - e.g.:
Robot::juiceIt(Orange *o)
{
// ...
}
Robot::sliceIt(Apple *a)
{
// ...
}
Robot::peelIt(Banana *b)
{
// ...
}
Orange::process(Robot *r)
{
r->juiceIt(this);
}
Apple::process(Robot *r)
{
r->sliceIt(this);
}
Banana::process(Robot *r)
{
r->peelIt(this);
}

Answer 3

I think #meagar has the better solution but I want to put this out there.
Robot::processFruit(List<Fruit*> basket)
{
foreach(Fruit *fruit, basket)
fruit->process(*this);
}
Orange::process(Robot & robot) {
robot.JuiceIt(*this);
}
This solution say a fruit needs a robot to process it.

Answer 4

If I really, really needed to solve this problem and I couldn't engineer my way around it... I'd write a type-aware double dispatch processor, and use it as a single-dispatch on the argument type only.
First, write a functions class that is a type erased function overload set. (This isn't trivial!)
typedef functions< void(Apple*), void(Orange*), void(Banana*) > processors;
Second, maintain a set of FruitTypes in a compile time list:
type_list< Apple, Orange, Banana > CanonincalFruitTypes;
typedef functions< void(Apple*), void(Orange*), void(Banana*) > FruitProcessor;
this has to be maintained somewhere. The relationship between these two lists can be automatic with a bit of work (so FruitProcessors is produced from CanonicalFruitTypes)
Next, write a reflection style dispatch:
class Fruit {
public:
virtual void typed_dispatch( FruitProcessor ) = 0;
virtual void typed_dispatch( FruitProcessor ) const = 0;
};
template<typename Derived>
class FruitImpl: public Fruit {
static_assert( std::is_base< Derived, FruitImpl<Derived> >::value, "bad CRTP" );
static_assert( /* Derived is in the Fruit type list */, "add fruit type to fruit list" );
Derived* self() { return static_cast<Derived*>(this); }
Derived const* self() const { return static_cast<Derived*>(this); }
virtual void typed_dispatch( FruitProcessor f ) final overrode {
f(self());
}
virtual void typed_dispatch( FruitProcessor f ) const final overrode {
f(self());
}
};
Use tricks to make deriving from Fruit not through a FruitImpl illegal (friend and private based stuff).
then, the Robot can go to town:
void Robot::process( Fruit* fruit ) {
fruit->typed_dispatch( MyHelperFunctor(this) );
}
where MyHelperFunctor returns a functor with overrides for the various types of Fruit the Robot can handle, and functions<...> has to be smart enough to test that each signature it supports can be handled by the passed in functor (this is the non-trivial part) and do proper dispatch to them.
If someone derived from Fruit, they do it via FruitImpl, which enforces it being in the fruit list. When the fruit list changes, the typed_dispatch signature changes, which requires that all users of it implement an override that can accept every fruit type in the list.
This allows you to decouple the virtual behavior of Fruit when processed by a Robot from the Fruit implementation itself, while enforcing compile-time checks that all types are handled. If their is a hierarchy of Fruit, the Robot's helper functor can make compile-time decisions to dispatch the call based on that heirarchy (which is translated into a run-time decision in functions). The overhead is an extra virtual function call (for the type-erased functions), and the construction of the type-erased functions object.

Answer 5

This is almost a text book case for the Visitor pattern. In the sample below I'm not using the standard visitor pattern class or function names, rather I'm using names that are relevant to the domain in this case - i.e. FruitProcessor and Process, rather than Visitor and Apply. I'm not going to comment much further as I think the code is pretty self explanatory other than to mention that this design requires the FruitProcessor to be manually updated when adding more types of fruit. There are various ways to handle that including registering fruit processing handlers or even using an abstract fruit processing factory (see abstract factory for more details). I would like to mention that there is another way that definitely requires a look and that was presented at boostcon by Sean Parent: see it on Youtube: Value Semantics and concept based polymorphism
class Apple;
class Orange;
class FruitProcessor
{
public:
virtual void Process(Apple& apple) = 0;
virtual void Process(Orange& orange) = 0;
};
class Fruit
{
public:
virtual void Process(FruitProcessor& proc) = 0;
};
class Apple : public Fruit
{
public:
virtual void Process(FruitProcessor& proc) override
{
proc.Process(*this);
}
};
class Orange : public Fruit
{
public:
virtual void Process(FruitProcessor& proc) override
{
proc.Process(*this);
}
};
class RobotFruitProcessor : public FruitProcessor
{
public:
virtual void Process(Apple& apple) override
{
std::cout << "Peel Apple\n";
}
virtual void Process(Orange& orange) override
{
std::cout << "Juice Orange\n";
}
};
int main()
{
std::vector<Fruit*> fruit_basket;
fruit_basket.push_back(new Apple());
fruit_basket.push_back(new Orange());
RobotFruitProcessor rfp;
for(auto f : fruit_basket)
{
f->Process(rfp);
}
return 0;
}