I frequently see people extending a class like this for example:
public class Bananas extends Fruits {
public void eatFruit(){
}
}
rather than
public class Bananas {
Fruits fruitsObject = new Fruits();
fruitsObject.eatFruit();
}
What is the reason behind doing one rather than the other? I was taught to use the second example, but I usually see people using the first example.
Your two examples define two different ways of combining bananas and fruit.
In your first example Bananas are a type of Fruits as they have all of the features of Fruits as part of themselves as well as any features you decide to add specifically to Bananas. Were you to pass a Bananas object to a function you could pass it to a function expecting a Bananas or, as many programmers find more useful, you could pass your Bananas object to a function expecting a Fruits! (You could also define Apples, Pears, etc. and pass those to that same function!)
In your second example Bananas contain a Fruits and conceptually are not Fruits. With that concept you can not add to the features of Fruits as it is represented within Bananas. Those features are set when the Fruits class was created. You could, technically, access the Fruits within your instantiated objects of Bananas and therefor have access to the public features of Fruits as part of your Bananas object but were you to ever want to pass an object of class Bananas to a function that function would have to specifically be expecting a Bananas...not a Fruits. (Were you to then define Apples, Pears, and the like you could not pass them to your function as it only accepts Bananas.)
For that matter, in your first example you are CREATING a new function within Bananas while in your second example you are merely CALLING a function called eatFruit that already existed in Fruits.
You were taught to use the second example? That's totally weird. You should examine what you need in a particular situation, and use the thing that is appropriate in that situation.
And be very, very careful with classes that pretend to mimic real life objects. In your case, it starts with the class name: Fruits? Bananas? I might consider having a class where an instance represents one fruit, but a class where an instance represents fruits? And then another class whose instances represent bananas? Not one banana, but bananas? That is one weird class design.
With the first example you're expressing precise relationship as in "one being the type of the other" and with that comes the benefits of inheritance and polymorphism, whereas in the second example you're providing accessibility to the methods and data of some class within the context of the other. If both the Fruits and Bananas class are not within the same package and then you want to access protected members of Fruits directly within Bananas, you will get an error, but with inheritance as the first example you can access protected members of the superclass directly within its subclass.
