Can Polymorphysim be achived using composition ins

Question

I am learning Java, I know what inheritance and composition is, I saw numerous examples of polymorphysim showed using inheritance, so my first question is,can same be done using composition? If yes, please show with a small example.

My second question is, can it be said that polymorpysim is basically method overloading and/or is method overiding ? if yes, then why ?

Answer 1

First question

Polymorphism can be achieved in Java in two ways:

• Through class inheritance: class A extends B
• Through interface implementation: class A implements C.

In the later case, to properly implement A's behaviour, it can be done though composition, making A delegate over some other class/es which do the tasks specified in Interface C.

Example: Let's suppose we have already some class imeplementing interface C:

class X implements C
{
    public String getName() {...}
    public int getAge() {...}
}

How can we create a new class implementing C with the same behaviour of X? Like this:

class A implements C
{
    private C x=new X();
    public String getName() {return x.getName();}
    public int getAge() {return x.getAge();}
} 

Second question

No, polymorphism is not method overloading and/or method overriding (in fact, overloading has nothing to do with Object Oriented Design):

• Method overloading consists on creating a new method with the same name that some other (maybe inherited) method in the same class but with a different signature (=parameter numbers or types). Adding new methods is OK, but that is not the aim of polymorphism.
• Method overriding consists on setting a new body to an inherited method, so that this new body will be executed in the current class instead of the inherited method's body. This is a advantage of polymorphism, still is not the base of it either.

Polymorphism, in brief, is the ability of a class to be used as different classes/interfaces.

Answer 2

No, not really. Polymorphism and composition or aggregation (composition is a more rigid form of aggregation wherein the composed objects' lifetimes are tied together) are different ways of reusing classes.

Composition involves aggregating multiple objects to form a single entity. Polymorphism involves multiple objects that share analogous behavior.

For example, a Car object might be composed of two Axle objects, a Chassis object, four Wheel objects (which themselves may be composed of a Rim, a Tire, six LugNuts and so on). When you instantiate a Car, your Car constructor would instantiate all the parts that go along with it. That's composition. (Aggregation would use all the same part objects but not necessarily instantiate them in its constructor.)

A Car object might also not be useful on its own, but rather as a blueprint for numerous more specialized implementations of cars, such as SportsCar, SUVCar, SedanCar, and the like. In this case, the Car object might define a Car interface that would define common behaviors such as Steer, HitTheGas and Brake, but leave the implementations of those behaviors to the implementing classes. Then, a consumer of a Car object can declare an object of type Car, instantiate it as any of the implementing classes such as SportsCar, call the methods defined in the Car interface, and get the behavior implemented in the instantiated class. That's polymorphism.

For a decent tutorial on both, with some comparisons, have a look at this. Keep in mind that the UML diagrams have an inaccuracy: while the examples do indeed describe composition as opposed to aggregation, the related UML class diagrams have white diamonds where they should be black. UML class diagram syntax uses a white diamond for class associations that are aggregations and a black one for those that are compositions.

Also, this post has some good information, in particular tdammers's answer halfway down the page.

Answer 3

There is book answer, if one remember about all the firemans are fireman but some are drivers, chiefs etc. There you need polymorphism. There is things you can do with classes and it's a general idea in OOP as language constraints. Overriding is just what you can do with classes. Also permissions and local and/or global scopes. There is default constructor for any class. There is namespace scope, program, class etc.

All Classes and methods are functions but not all functions are methods

You can override class but not method. Those are static or volatile. Cos method can only return the value. So overriding the method has no sense. I hope this will turn you, if nothing, toward how it was meant to be. Inheritance is mechanism how polymorphism works.

My apologies for unintentional mistakes during too much data.