• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Polymorphism, Encapsulation and Inheritance

steppinthrax

Diamond Member
I understand that Encapsulation simply means the language has the ability to "seperate" or allow the creation of modules where the internal functionality of each function or class is irrelavent to the designer. In other words all you need to care about is the inputs and outputs of the function or class. I.E. the black box.... Am I correct?

In Inheratance you create a parent class with operators and create a child class or subclass with operators. You call a method within the child class to inheret operators of the parent class. I saw example codes of this being done in JavaScript. What I'm confused about is it seems polymorphism is pretty similar to Inheritance in the fact that you can have the subclass inherite operators from the parent class and Over-ride the operators from the parent class. It seems like you are Inheriting and polymorphism at the same time????

Can you Inherit but not polymorph????
 
To me:

Inherit is to use what is exposed as public/protected in the base class.

Polym is changing (replacing) the operational function in the base class with one of your own.
 
Originally posted by: Common Courtesy
To me:

Inherit is to use what is exposed as public/protected in the base class.

Polym is changing (replacing) the operational function in the base class with one of your own.


That is what I was thinking.

So in this example.....

function superClass() {

this.bye = superBye;
this.hello = superHello;
}

function subClass() {
this.inheritFrom = superClass;
this.inheritFrom();
this.bye = subBye;
}

function superHello() {
return "Hello from superClass";
}

function superBye() {
return "Bye from superClass";
}


function subBye() {
return "Bye from subClass";
}

function printSub() {
var newClass = new subClass();
alert(newClass.bye());
alert(newClass.hello());
}

The superclass is a parent class while the subclass is the child. It seems Inheratance is going on when the method

this.inheritFrom = superClass;
this.inheritFrom();

is used. However the subclass also OVER RIDES this.bye = subbye. Is that a form of Polymorphism????

So this demonstrates poly as well as inheratance?
 
Polymorphism is a separate idea from inheritance although inheritance can use polymorphism vice versa. It involves being able to accept different data types in a uniform way.

The most common use is writing multiple functions with the same name(think of the print command in Java, it uses all types) but each one takes different input data types(one might take integers and the other might take doubles or any other data type). The goal is to simplify usage at a high level. It makes no difference at the lower levels because different operations are being done depending on the data type. It allows the the coder to abstract the code. You could just write intDivide or doubleDivide, and it would be the same thing.

You can read about it on wikipedia.
 
I would suggest reading up on the prototype object if you're learning ES3 (core Javascript) as that's the only native way of inheritance.
 
He's obviously in an early level OOP course. The relevant wiki page is This one.



AFAIK, you cannot inherit but not polymorph - polymorphism, at it's core, is the simple fact that you can put an object of a derived class into a variable defined as the parent class.

IE, Class GreatDane inherits from Class Dog. Even if GreatDane doesn't override any of Dog's methods - I can always do this:

GreatDane MyDog = new GreatDane();
Dog ADog = MyDog;

or even this:

Dog MyNeighborsDog = new GreatDane();


Thus, inheritance without polymorphism is essentially impossible.

Now, it may not seem very useful here, but there is still a purpose. Say Dog has one method, Bark(). GreatDane inherits that Method, and adds a new method, fetchMeADanishBoy(). I can put MyDog in a collection or array of other dogs and have them do Dog things together, but I can still have MyDog do GreatDane things.

EX:

Dog[] Kennel = new Dog[2];

GreatDane MyDog = new GreatDane();
Dog[0] = new Dog();
Dog[1] = new Dog();
Dog[2] = MyDog;

for (Dog thisDog : Kennel)
{
thisDog.bark();
}

MyDog.fetchMeADanishBoy();



In the loop, all dogs, including MyDog, are being treated as Dogs, and thus can bark. MyDog is still a GreatDane, and thus can fetch me a danish. But here's the catch - when MyDog is part of Kennel, the compiler thinks he's just a dog. So I couldn't do this:

for (Dog thisDog : Kennel)
{
thisDog.fetchMeADanishBoy();
}


Dog has no method fetchMeADanishBoy, so the compiler will yell at me. It's worth noting that even if every member of the Kennel array was a GreatDane, it still wouldn't work, as the Kennel is an array of Dogs, and more importantly, thisDog is declared as a Dog.




So there you have it. It becomes much more useful, of course, when you're actually overriding methods. And to be perfectly blunt, inheritance based polymorphism isn't something I've seen a lot of use for in practical coding. Polymorphism doesn't become really, really useful until you bring in the concept of interfaces.
 
To build on what the others have said, polymorphism and inheritance really are separate concepts.

Think of inheritance as implementing an "is-a" relationship between two things. For example, a Square is a Rectangle, and a Rectangle is a Polygon. Everything that a Polygon is, a Rectangle also is, and in turn a Square is everything a Rectangle is. Each derived type, or subclass, inherits all the characteristics of the thing it derives from, and adds the things that make it different (as a square adds a constraint on the lengths of the sides). Inheritance is mostly about economy and encapsulation.

"Polymorphism" is a thirty cent word with a five cent meaning. It's not even that great a word. It means "many forms" but that leaves out the important part: "many forms that can be used similarly." All it means is that it may make sense for a class of objects to say that every member of the class or any derived class can do some thing, whatever it is, without saying exactly how it is done. A class Vehicle might introduce a virtual method "Decelerate". An Automobile class would implement this method by actuating the disk brakes. A Truck class might activate the brakes and downshift. A Speedboat class would reduce the throttle.

The point is that some abstract "Driver" class that has to know how to handle Vehicles can assume that every Vehicle implements Decelerate, and use that to slow the vehicle down, without worrying about whether the Vehicle is a Car, Truck, or Speedboat. So polymorphism is primarily about flexibility and resilience. The simple code in the abstract Driver class won't have to change when new Vehicles are added. A popular means of implementing polymorphism is through interfaces, which is one way of demonstrating that inheritance isn't required.

Inheritance in fact has proven difficult to manage in real-world systems for various reasons stemming from the compile-time type-based nature of the relationship. Interfaces have proven more robust and flexible. I would go as far as to say that the primary use of inheritance is in implementation-level class frameworks like .Net where the problem domain is very stable and somewhat artificial. When you get into the actual problem domain it's hard to do it well.

 
This is gonna be a book. Sorry if you don't like to read much.

Originally posted by: steppinthrax
Originally posted by: Common Courtesy
To me:

Inherit is to use what is exposed as public/protected in the base class.

Polym is changing (replacing) the operational function in the base class with one of your own.


That is what I was thinking.

So in this example.....

function superClass() {

this.bye = superBye;
this.hello = superHello;
}

function subClass() {
this.inheritFrom = superClass;
this.inheritFrom();
this.bye = subBye;
}

function superHello() {
return "Hello from superClass";
}

function superBye() {
return "Bye from superClass";
}


function subBye() {
return "Bye from subClass";
}

function printSub() {
var newClass = new subClass();
alert(newClass.bye());
alert(newClass.hello());
}

The superclass is a parent class while the subclass is the child. It seems Inheratance is going on when the method

this.inheritFrom = superClass;
this.inheritFrom();

is used. However the subclass also OVER RIDES this.bye = subbye. Is that a form of Polymorphism????

So this demonstrates poly as well as inheratance?

You's using 'class' in the names of methods. I'd encourage some wikipedia-ing and an intro CS course. I'll try an explanation, to be taken with a grain of salt.


What you're talking about seems to be method overloading, which is also called overriding polymorphism. Wikipedia's example is two classes which have the same parent class, Dog and Pig. A Pig's speak() method will output "oink," while a Dog's will output "bark." A generic animal might just "speak" when speak() is called. In this case, a different function will be called based on the context in which the call is made. Because of this, overriding polymorphism is a concept strongly tied to inheritance, and you can't have o.p. without inheritance. You can have parametric polymorphism, though.

Parametric polymorphism lets us have a bunch of methods with the same name, but different arguments.

public static void main(String args[])
{
int i = 3;
String s = "I'm a String!";
print(i);
print(s);
}

public void print(String arg)
{
System.out.print(arg);
}

public void print(int arg)
{
System.out.print(arg);
}

will output "3I'm a String!". If you tried this in a language which doesn't allow parametric polymorphism, your compiler or interpreter will squawk at you; php gives something along the lines of "function print already defined".

Note that in the example above, the functions do approximately the same thing. This isn't always the case. You could make a print(double) function which shut the user's machine off, if you want to.

Kinda neat thing which comes back to overriding polymorphism: it's how the + operator does different things in different contexts. For instance, if I do + between two strings, it is concatenation. Between two numeric types, it's addition. If you want, you can overload the + operator to delete one of the arguments and print "I'm a hamster;" what you'd be doing boils down do overriding polymorphism.
 
You think he's actually talking about Javascript, and not Java and simply misspoke? Really, these kind of questions absolutely scream "Compsci 102: Fundamentals of OOP", and they're often taught in Java, and never in JS.
 
Ad-hoc polymorphism = inheritance
Parametric polymorphism = polymorphism (this is the most common way of expressing polymorphism)

You can use inheritance without polymorphism(just not without ad-hoc polymorphism which is inheritance in the first place). If you don't overload a method, constructor or destructor, then you haven't used polymorphism. If you want to use ad-hoc polymorphism, just inherit the class members and don't override them.

inheritance has overriding
polymorphism has overloading

If inheritance is the modern term for describing generalization and specialization of classes, then ad-hoc polymorphism is obsolete and should not be referred to as polymorphism.

*edit*
Lets clean up your psuedo code too

EX:

Dog[] Kennel = new Dog[2];

GreatDane MyDog = new GreatDane();
Kennel[0] = new Dog();
Kennel[1] = MyDog;
 
Allright, lets see if we can get this straight.

In terms of OOP, what used to be called Parametric Polymorphism is no longer refered to Polymorphism at all. It's called Generic Programming.

Polymorphism refers specifically to what used to be called Ad-hoc polymorphism, and covers three distinct, disjoint areas - Interface Implemenation, Class Inheritance, and Method Overloading. As such, OOP polymorphism has overriding, overloading and implementation.



From this we can determine precisely one thing: Computer Scientists at large are at best, guilty of changing terms more often the marketing junkies change buzzwords. Far more likely, they're guilty of purposeful Obfuscation - something which I have suspect ever since I laid eyes on Assembler and C.
 
Originally posted by: PhatoseAlpha
Allright, lets see if we can get this straight.

In terms of OOP, what used to be called Parametric Polymorphism is no longer refered to Polymorphism at all. It's called Generic Programming.

Polymorphism refers specifically to what used to be called Ad-hoc polymorphism, and covers three distinct, disjoint areas - Interface Implemenation, Class Inheritance, and Method Overloading. As such, OOP polymorphism has overriding, overloading and implementation.



From this we can determine precisely one thing: Computer Scientists at large are at best, guilty of changing terms more often the marketing junkies change buzzwords. Far more likely, they're guilty of purposeful Obfuscation - something which I have suspect ever since I laid eyes on Assembler and C.

Nice!
 
Back
Top