Polymorphism

[Smita Chopra]

I have read that polymorphism is about overriding but is it about overloading as well.
Thanks

[Chetan Parekh]

Polymorphism is a concept of OOPS.

When you apply the concept of polymorphism in same class, Java calls it Overloading.
When you apply the concept of polymorphism in inheritance, Java calls it Overriding.

[Georgy Bolyuba]

I was always thinking that Polymorphism is about Overriding and never include Overloading in Polymorphism. However, I saw a lot of diffinition of Polymorphism and in all cases there was nothing about Orevloading.

Chetan Parekh, can you name you source which says that Overloading is a polymorphism in same class?

[Ilja Preuss]

See this recent discussion: https://coderanch.com/t/400110/java/java/Compile-time-Runtime-polymorphism

[Georgy Bolyuba]

Ilja, thanks. It seems much clear now about "what should I call Polymorphism".

Let me ask you one more question about OO paradigms.

Is this code breaking Encapsulation paradigm? (One object is accessing private member of another object.)

class A{
  private i;
 
  public A(int ii) {i = ii;}
 
  public void print(A a) { System.out.println(a.i); }
 
  public static void main(String[] arguments)
  {
    A a1 = new A(10);
    A a2 = new A(20);
 
    a2.print(a1);
  }
}

[Ernest Friedman-Hill]

Java and C++ have class-based encapsulation. Some OO languages (Ruby, if I recall, and perhaps Python?) have object-based encapsulation. I personally don't think one is "better" than the other; class-based encapsulation certainly makes it easy to implement operations like clone() and equals() that are harder to do in an object-encapsulation language, although object-based encapsulation is perhaps more intuitive.

[Georgy Bolyuba]

Ernest Friedman-Hill, Thank you.

class-based encapsulation certainly makes it easy to implement operations like clone() and equals()...

I've read about "object can access private member of another object of the same class" during my SCJP 1.4 preparation in chapter about equals() overriding.

[Ilja Preuss]

Originally posted by George Bolyuba:
Is this code breaking Encapsulation paradigm?

Only minimally, in my view.

First, you are probably referring to what I would call information hiding. Encapsulation, in my understanding, refers to putting things together that are closely coupled, such as data and the operations on that data. Information hiding is about hiding internal details from the outside.

Second, we need to take a look at *why* we want information hiding. The main reason for hiding fields is to manage source code dependencies - for example, we want to minimize the number of places we have to touch should we need to change something (because we well have to regularly). In your example, when "i" needs to be changed, we still don't have to touch any other classes but A, so change impact is already quite localized.

Of course by using a getter in even this case, we could minimize the impact of some changes, such as the introduction of lazy initialization for "i" even more. On the other hand, information hiding (as well as all the other OO principles such as encapsulation, decoupling etc.) isn't something that you want to do "100%" - it needs to be balanced against all the other needs of the code, such as functionality, simplicity etc.

After all, a class that conforms 100% to information hiding and/or decoupling would be useless, as it couldn't provide an interface to its clients...

Does that help?

[Georgy Bolyuba]

Does that help?

Yes. It seems clear and helpfull. Thanks.

[Layne Lund]

Originally posted by Smita Chopra:
I have read that polymorphism is about overriding but is it about overloading as well.
Thanks

TRUE!

So did you have an actual question, or did you visit to just tell us this fact?

[Smita Chopra]

Originally posted by Layne Lund:


TRUE!

So did you have an actual question, or did you visit to just tell us this fact?

Head First Java says that overloading has nothing to do with polymorphism while elsewhere I have read (can't recall the resource right now) both overloading and overriding are examples of polyporphism, hence the confusion.

[Mr. C Lamont Gilbert]

Overloading has nothing to do with polymorphism. The example you gave does violate encapsulation and will bring along with it all the negative effects of that violation. Most promanently, you can't change the inside of one class without it affecting the behavior of another class.

[Ilja Preuss]

Originally posted by CL Gilbert:
Overloading has nothing to do with polymorphism.

Yes, it has. The more generic definition of polymorphism includes method overloading as a form of "compile time polymorphism". Check the thread I referenced above.

The example you gave does violate encapsulation and will bring along with it all the negative effects of that violation. Most promanently, you can't change the inside of one class without it affecting the behavior of another class.

I don't see how his example has this property, as the field is still private and therefore can only be used inside the declaring class.

[Smita Chopra]

Page 187, Head First Java

There is no polymorphism involved with overloaded methods.

Is the book incorrect when it says, no polymorphism with overloaded methods?

[Ilja Preuss]

Originally posted by Smita Chopra:
Is the book incorrect when it says, no polymorphism with overloaded methods?

Strictly speaking, I would say it is, yes.

I don't have the book at hand, though. Perhaps earlier in the book there is some definition of the term that clarifies what the authors mean when they use it?