Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Polymorphism

 
Smita Chopra
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have read that polymorphism is about overriding but is it about overloading as well.
Thanks
 
Chetan Parekh
Ranch Hand
Posts: 3640
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
See this recent discussion: http://www.coderanch.com/t/400110/java/java/Compile-time-Runtime-polymorphism
 
Georgy Bolyuba
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.)

 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Does that help?


Yes. It seems clear and helpfull. Thanks.
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 45
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic