No subject

don't see how those functions are going to change during execution of the 
code.  I'm really confused by your example, but in general, using OO 
principals, you are essentially hiding the specific implementation behind a 
generic interface.  The generic interface is something that is Edible.  The 
specifics of what happens when you call it on an instance of Edible should 
be irrelavent to the calling code.  It just knows that something needs to be 
eaten, it doesn't care how that is done :)  Imagine later on down the road 
you need to add another fruit.  This is trivial, just add it to the 
initialized array, and every instance that calls get() doesn't care that 
get() can now return another fruit type.  If you had your switch statement, 
then you have to update it in the calling code.  You could even dynamically 
map values to fruits.  All this, and the caller of get() doesn't have to 
care what fruits there are, and how they are used.  It just knows that 
whatever is returned from get() has an eat() function which it needs to 
call.

Separating interface from implementation is not only useful, but is more 
understandable, maintainable, and generally contains less bugs.  That's not 
to say you have to use OO principals to solve every problem, but a problem 
in which you are calling a similar function on lots of similar objects (or 
modules) screams to be solved with OO :)  You should find a good book on 
design patterns, they are immensely useful and mostly universal (though 
usually geared towards Java).  I'm sure there is one that solves this.

-Steve