Polymorphism without inheritance

Some script languages support it. How to do it in Java?

Jane,
Do you mean polymorphism through interfaces? Or something more like JavaScript where the language "discovers" the type based on whether the method/field is present? Or something else entirely?

If you mention the language you are thinking of that has it, we could know which of these are under discussion and someone could reply more specifically.

Python is weak typed script language. It can support "Polymorphism without inheritance".

Java is a strong typed language. It is impossible to do "Polymorphism without inheritance".

Python is weak typed script language. It can support "Polymorphism without inheritance".

Java is a strong typed language. It is impossible to do "Polymorphism without inheritance".

Both Python and Java are strong-typed languages. But Python is a dynamic language whereas Java is a static language. There is a difference between strong/weak versus dynamic/static.

Python is weak typed script language. It can support "Polymorphism without inheritance".

Jane, it would be helpful if you could explain what you mean by this. How does Python support the OO design concept of polymorphism without using inheritance of either a concrete class or an interface class.

James Clark wrote:
Jane, it would be helpful if you could explain what you mean by this. How does Python support the OO design concept of polymorphism without using inheritance of either a concrete class or an interface class.

In short: With dynamically typed languages, types are checked at runtime instead of compile time. When you call a method on an object, the runtime environment checks whether that object has an implementation for that specific method. If so, it gets called polymorphically; if not, you get a runtime error (*).

If you google for "static versus dynamic typing" you will get lots of articles on the topic.

(*) Assuming that it's a *strongly* typed language, like Smalltalk.

When you call a method on an object, the runtime environment checks whether that object has an implementation for that specific method. If so, it gets called polymorphically;

What is "polymorphic" about this process?


A JRE does a similiar check at runtime as well.

James Clark wrote:

When you call a method on an object, the runtime environment checks whether that object has an implementation for that specific method. If so, it gets called polymorphically;

What is "polymorphic" about this process?

The method implementation used is determined at runtime, depending on the implementation of the object.

A JRE does a similiar check at runtime as well.

The major difference is that there is also a check done at compile time. Because at that time there actually is no object to check, the check is done based on the type of the object *reference*. Referenced objects are then required to be instances in an inheritance relationship with the declared type.

In dynamically typed languages, object references aren't typed, the inheritance relationship is not required.

(This actually is a little bit of a simplification - as far as I know there are languages (at least in development) that are statically typed and don't require inheritance for polymorphism. None of them made it into mainstream yet, though.)

The method implementation used is determined at runtime, depending on the implementation of the object.

An object only has a single implementation ... at all times. I don't see anything "polymorphic" in this description.

The method implementation to execute is always determined at run-time, it is never determined during compilation.

(Polymorphism compilation rules) and (Polymorphism run-time behavior) are different concepts, and handled by different code.

James Clark wrote:

The method implementation used is determined at runtime, depending on the implementation of the object.

An object only has a single implementation ... at all times. I don't see anything "polymorphic" in this description.

It's simply the definition of (runtime) polymorphism, as far as I can tell. What definition are you using?

The method implementation to execute is always determined at run-time, it is never determined during compilation.

Not true for static methods in Java.

(Polymorphism compilation rules) and (Polymorphism run-time behavior) are different concepts, and handled by different code.

And still they are linked.

Anyway, here is a concrete example:

Before Java 1.5, it was impossible to write code like this



that worked for both InputStreams and Readers, for example, simply because they didn't share a common base class/interface in which that method was defined. In Java 1.5 they introduced the Closeable interface to enable that.

In a dynamically typed language, the above code would simply work for every object that has a close() method, without any need for a common base class or interface (in fact, those languages don't have any need for Java-like interfaces at all).

I hope that makes it more clear.

C++ allows generic points, which make it possible that Class A behaves as Class B at runtime even Class A and B do not have a common base Class.

The only way to do it in Java is to use reflection. And that's clumsy.

In Java we can implement polymorphism by using interface or inheritance.
So an answer of this question is using interface.

Or you mean you don't want to use both interface and inheritance?

Kengkaj Sathianpantarit wrote:In Java we can implement polymorphism by using interface or inheritance.
So an answer of this question is using interface.

Or you mean you don't want to use both interface and inheritance?

Interfaces are just a specialized form of inheritance.

Ilja Preuss wrote:

Kengkaj Sathianpantarit wrote:In Java we can implement polymorphism by using interface or inheritance.
So an answer of this question is using interface.

Or you mean you don't want to use both interface and inheritance?

Interfaces are just a specialized form of inheritance.

I don't think so. A class that *implements* an interface doesn't *inherit* anything.

From The Java Tutorials, Inheritance is about deriving classes.
http://java.sun.com/docs/books/tutorial/java/IandI/subclasses.html

Kengkaj Sathianpantarit wrote:I don't think so. A class that *implements* an interface doesn't *inherit* anything.

A specialized form of inheritance, and I disagree: it inherits the interface definition--just not any behavior.

Interfaces are a replacement for multiple inheritance.

David Newton wrote:

Kengkaj Sathianpantarit wrote:I don't think so. A class that *implements* an interface doesn't *inherit* anything.

A specialized form of inheritance, and I disagree: it inherits the interface definition--just not any behavior.

Interfaces are a replacement for multiple inheritance.

I'd say that interfaces are in implementation of multiple interface inheritance (in contrast to implementation inheritance).

Ilja Preuss wrote:The only way to do it in Java is to use reflection. And that's clumsy.

How?

Kengkaj Sathianpantarit wrote:In Java we can implement polymorphism by using interface or inheritance.
So an answer of this question is using interface.

Or you mean you don't want to use both interface and inheritance?

Java is a language supports multiple inheritance through Interfaces, not Classes.

Kengkaj Sathianpantarit, the code below when compiled creates a class. In Java terms, it is an "interface" class.



The code below when compiled creates a class. In Java terms, it is a "concrete" class.



Java supports multiple inheritance of "interface" classes.

Java does not support multiple inheritance of "concrete" classes.

This is not rocket science and had been discussed in multiple posts prior to this one.

strange - I don't think I've ever heard the the term interface class before. Google doesn't seem to know much about it either.

David Newton wrote:

Kengkaj Sathianpantarit wrote:I don't think so. A class that *implements* an interface doesn't *inherit* anything.

A specialized form of inheritance, and I disagree: it inherits the interface definition--just not any behavior.

Interfaces are a replacement for multiple inheritance.

No it's no inheritance. From a dictionary "inherit" means derives from parents.
When a class implements an interface, it doesn't inherit definition, because it has to declare the methods *again* (or inherits from a superclass).

Interfaces are a way to offer features of multiple inheritance, but implementing an interface is not inheriting.

Jane Somerfield wrote:

Kengkaj Sathianpantarit wrote:In Java we can implement polymorphism by using interface or inheritance.
So an answer of this question is using interface.

Or you mean you don't want to use both interface and inheritance?

Java is a language supports multiple inheritance through Interfaces, not Classes.

No, Java has no Multiple Inheritance, using interfaces is a way to do what can be achieved by using multiple inheritance.

2.2.5 No More Multiple Inheritance

Multiple inheritance--and all the problems it generates--was discarded from Java. The desirable features of multiple inheritance are provided by interfaces--conceptually similar to Objective C protocols.

http://java.sun.com/docs/white/langenv/Simple.doc2.html

Interfaces and Multiple Inheritance
Interfaces have another very important role in the Java programming language. Interfaces are not part of the class hierarchy, although they work in combination with classes. The Java programming language does not permit multiple inheritance (inheritance is discussed later in this lesson), but interfaces provide an alternative.

http://java.sun.com/docs/books/tutorial/java/IandI/createinterface.html

Ilja Preuss wrote:strange - I don't think I've ever heard the the term interface class before. Google doesn't seem to know much about it either.

I think he means when compile an interface we get a .class file.
I've heard term "interface classes" from a C++ guy, it means abstract classes that have only virtual functions. But it's not a commonly accepted term.

Back into the topic, I don't think it would be possible in Java to do polymorphism without using inheritance or interface because Java is a statically typing language.

Unfortunately, Sun isn't a very reliable source when it comes to definition of computer science terms. You should look up interface inheritance on wikipedia...

When a class "inherits" from an interface class, it "inherits" method contracts, method responsibilities which are "defined" in the interface class. It makes a statement that this is "who" I am and this is "what" I can do." It "inherits" the behavior "defined" in the interface class.

The only thing that is not "inherited" is the implementation code of the behavior. The primary concept here is that the
the responsibilities of the class are "inherited".

A "deeper" understanding of what an object-oriented "class" is might be helpful.

There is much more to "inheritance" than meets the eye

Good luck!

Jane Somerfield wrote:

Ilja Preuss wrote:The only way to do it in Java is to use reflection. And that's clumsy.

How?

Here's some code that's pretty much how you do it. (I typed this without a compiler so it might not be 100%. Google "reflection invoke method" for a full example. I was trying to focus on the steps/pseduocode.)


This isn't something you want to do for the purpose of inheritance though. For a basic construct like that, it's better to use what the language supports - interfaces. That way when people read the code, it uses the standard Java idioms.

Reflection does have a use - when you are writing utilities or don't have the ability to force interfaces on the objects they deal with.

Jeanne Boyarsky wrote:

Jane Somerfield wrote:

Ilja Preuss wrote:The only way to do it in Java is to use reflection. And that's clumsy.

How?

Here's some code that's pretty much how you do it. (I typed this without a compiler so it might not be 100%. Google "reflection invoke method" for a full example. I was trying to focus on the steps/pseduocode.)

If myObject is a parameter of a method, myObject's type also needs to be java.lang.Object to allow passing different types to the method (or use a superclass/interface as its type).

But in that case, it does means that we still use inheritance as all Java classes extend java.lang.Object.

Jeanne Boyarsky wrote:
Here's some code that's pretty much how you do it. (I typed this without a compiler so it might not be 100%. Google "reflection invoke method" for a full example. I was trying to focus on the steps/pseduocode.)


This isn't something you want to do for the purpose of inheritance though. For a basic construct like that, it's better to use what the language supports - interfaces. That way when people read the code, it uses the standard Java idioms.

Reflection does have a use - when you are writing utilities or don't have the ability to force interfaces on the objects they deal with.

It is not polymorphism. Your containing class consists of a class of clazz. So the behave of clazz is part of the containing class.

Jane Somerfield wrote:

Jeanne Boyarsky wrote:
Here's some code that's pretty much how you do it. (I typed this without a compiler so it might not be 100%. Google "reflection invoke method" for a full example. I was trying to focus on the steps/pseduocode.)


This isn't something you want to do for the purpose of inheritance though. For a basic construct like that, it's better to use what the language supports - interfaces. That way when people read the code, it uses the standard Java idioms.

Reflection does have a use - when you are writing utilities or don't have the ability to force interfaces on the objects they deal with.

It is not polymorphism. Your containing class consists of a class of clazz. So the behave of clazz is part of the containing class.

And even if myObject is a parameter its type has to be java.lang.Object or a superclass or an interface, so using Reflection is not a solution.

Jane Somerfield wrote:
It is not polymorphism. Your containing class consists of a class of clazz. So the behave of clazz is part of the containing class.

Sorry, I don't understand what you are trying to say. What does "the behavior of clazz is part of the containing class" mean, and why is it therefore not polymorphism?

Jeanne's code is in fact exactly emulating how polymorphism is implemented in dynamically typed languages.

[deleted - see post below]

Ilja Preuss wrote:
Jeanne's code is in fact exactly emulating how polymorphism is implemented in dynamically typed languages.

Maybe so. But the question of this topic is how to implement without inheritance (and/or interface).

The question is what is myObject's type?
If myObject is a parameter, callers need to pass something to myObject, right?
Unfortunately Java is a statically typing language, so to pass a parameter we have to pass IS-A thing, and IS-A can be implemented by inheritance or interface.

Even if myObject's type is java.lang.Object, it still means we rely on inheritance mechanism since all Java classes extend from java.lang.Object.
Nevertheless this solution is close enough. If not using inheritance just means not using a superclass that define common methods, this solution is all right.

At least we have to use java.lang.Object because it's a language constraint, but we don't use it for polymorphism purpose.

Kengkaj Sathianpantarit wrote:If not using inheritance just means not using a superclass that define common methods, this solution is all right.

At least we have to use java.lang.Object because it's a language constraint, but we don't use it for polymorphism purpose.

I think that's what the original poster was asking about. I might be wrong, of course.