OOP Concepts

[Randy Charles Morin]

I'm looking for feedback on an article I wrote on OOP Concepts. The article
is at the following URL.
http://www.kbcafe.com/articles/oop.concepts.html
Thanks you very much for your time and sorry for the intrusion.
--
Randy Charles Morin
http://www.kbcafe.com/randycharlesmorin

[Ted]

"Randy Charles Morin" <rmorin@kbcafe.com> wrote:
>I'm looking for feedback on an article I wrote on OOP Concepts. The article
>is at the following URL.
>http://www.kbcafe.com/articles/oop.concepts.html
>Thanks you very much for your time and sorry for the intrusion.
>--
>Randy Charles Morin
>http://www.kbcafe.com/randycharlesmorin
>
>
>
>
>
>

I am curious as to how Inheritance and polymorphism act independently. Your
article makes it seem as though the two are different topics. It is impossible
to have polymorphism without Inheritance. Also your example code is completely
wrong.

Where is the inheritance in this example???
class A
{
public:
virtual void f()=0;
};

class B
{
public:
virtual void f()
{std::cout << "Hello from B" << std::endl;};
};

class C
{
public:
virtual void f()
{std::cout << "Hello from C" << std::endl;};
};

If I have an object A, then calling the method f() will produce different
results depending on the context, the real type of the object A.
func(A & a)
{
A.f();
};

A.f() doesn't work. If it did it would not be very polymorphic. a.f() would
be ok, but also not polymorphic because f() in A is always called no matter
the context as in B and C but func will never call B or C no matter the parameter
if there is no inheritance from A.

[Craig Clearman]

Ted,

>It is impossible to have polymorphism without Inheritance.

That depends on the language. Since the author of that piece was using
C++, I fully understand why you say that, and I agree. For C++,
polymorphism is implemented through inheritance.

As a general case, though, you don't need inheritance to achieve
polymorphism. These days, it is just as likely that you implement an
interface to achieve the same.

Ciao, Craig

[Ted]

OK, but the article was written in C++. Also, how would you have polymorphism
through interfaces? I assume you're talking COM?
Craig Clearman <chclear@nospam.please> wrote:
>Ted,
>
>>It is impossible to have polymorphism without Inheritance.
>
>That depends on the language. Since the author of that piece was using
>C++, I fully understand why you say that, and I agree. For C++,
>polymorphism is implemented through inheritance.
>
>As a general case, though, you don't need inheritance to achieve
>polymorphism. These days, it is just as likely that you implement an
>interface to achieve the same.
>
>Ciao, Craig
>

[Thomas Eyde]

Isn't polymorphism about having one object type behave as another? If you
have Animal, Cat and Dog classes and both Cat and Dog implements Animal's
interface then they can behave as the Animal.

Looks like polymorphism to me. Of course this is a kind of inheritance, we
are inheriting an interface.

But in Visual Basic you have a generic class called Object wich is late
bound. You may achieve polymorphism using this one. All polymorphic methods
and properties must have identical signatures.

/Thomas

"Ted" <TTarney@hotmail.com> wrote in message
news:3b1bdedb$1@news.devx.com...
>
> OK, but the article was written in C++. Also, how would you have
polymorphism
> through interfaces? I assume you're talking COM?
> Craig Clearman <chclear@nospam.please> wrote:
> >Ted,

[Ted]

Doesn't sound like polymorphism to me at all. What you are talking about
is containment not inheritance. You know (at compile time) what type of
object you are dealing with. I do not know how VB attempts to handle polymorphism,
but once again that the original article was written in C++ I will coment
on polymorphism in a real OO language.

You have an Animal, and Dog and Cat inherit from Animal. At some later time
you can pass Animal pointers that are actual Dog or Cat objects and access
the appropriate methods of either. Also are you talking objects or classes?
Again I don't know how VB attempts this, but if you are talking about implementing
objects that are created by COM objects( by the References dialog in VB)
then this is polymorphism because this is implementing VBTable binding( or
Late depending on how the object was implemented), once again something that
VB programmers know nothing about.

"Thomas Eyde" <thomas.eyde@eunet.no> wrote:
>Isn't polymorphism about having one object type behave as another? If you
>have Animal, Cat and Dog classes and both Cat and Dog implements Animal's
>interface then they can behave as the Animal.
>
>Looks like polymorphism to me. Of course this is a kind of inheritance,
we
>are inheriting an interface.
>
>But in Visual Basic you have a generic class called Object wich is late
>bound. You may achieve polymorphism using this one. All polymorphic methods
>and properties must have identical signatures.
>
>/Thomas
>
>"Ted" <TTarney@hotmail.com> wrote in message
>news:3b1bdedb$1@news.devx.com...
>>
>> OK, but the article was written in C++. Also, how would you have
>polymorphism
>> through interfaces? I assume you're talking COM?
>> Craig Clearman <chclear@nospam.please> wrote:
>> >Ted,
>
>
>

[Ted]

By the way since this is a design group I will put it this way:

A has-a relationship does not give polymorphic behavior. An Is-a does.

"Thomas Eyde" <thomas.eyde@eunet.no> wrote:
>Isn't polymorphism about having one object type behave as another? If you
>have Animal, Cat and Dog classes and both Cat and Dog implements Animal's
>interface then they can behave as the Animal.
>
>Looks like polymorphism to me. Of course this is a kind of inheritance,
we
>are inheriting an interface.
>
>But in Visual Basic you have a generic class called Object wich is late
>bound. You may achieve polymorphism using this one. All polymorphic methods
>and properties must have identical signatures.
>
>/Thomas
>
>"Ted" <TTarney@hotmail.com> wrote in message
>news:3b1bdedb$1@news.devx.com...
>>
>> OK, but the article was written in C++. Also, how would you have
>polymorphism
>> through interfaces? I assume you're talking COM?
>> Craig Clearman <chclear@nospam.please> wrote:
>> >Ted,
>
>
>

[Ted]

thanks for that. i don't know vb so that helps

Craig Clearman <chclear@nospam.please> wrote:
>Thomas,
>
>>Looks like polymorphism to me. Of course this is a kind of inheritance,
we
>>are inheriting an interface.
>
>Actually, you are not. You are implementing an interface instead.
>Inheriting an interface would allow you to extend that interface,
>instead of supplementing it with an additional interface. Visual Basic
>doesn't allow you to inherit an interface natively.
>
>Ciao, Craig
>

[Craig Clearman]

Thomas,

>Looks like polymorphism to me. Of course this is a kind of inheritance, we
>are inheriting an interface.

Actually, you are not. You are implementing an interface instead.
Inheriting an interface would allow you to extend that interface,
instead of supplementing it with an additional interface. Visual Basic
doesn't allow you to inherit an interface natively.

Ciao, Craig

[Craig Clearman]

Ted,

> Also, how would you have polymorphism through interfaces? I
> assume you're talking COM?

COM works this way, and so do most OO languages. Java, for instance,
has the ability to implement interfaces as a way to simplify the
language, as they have not implemented multiple inheritance. As such,
the only way that Java can be polymorphic with two unrelated classes
is to allow for interface implementation.

Ciao, Craig

[Thomas Eyde]

My comments inline.
/Thomas

"Ted" <TTarney@hotmail.com> wrote in message
news:3b1cd770$1@news.devx.com...
>
> Doesn't sound like polymorphism to me at all. What you are talking about
> is containment not inheritance. You know (at compile time) what type of
> object you are dealing with.

No. I did not talk about any implementation details. Just interfaces.

> I do not know how VB attempts to handle polymorphism,
> but once again that the original article was written in C++ I will coment
> on polymorphism in a real OO language.

I discussed polymorphism in COM. In C++ this obviously doesn't apply.
Off topic: What is a real OO language anyway. If you apply the common
criteria, no language will pass.

> You have an Animal, and Dog and Cat inherit from Animal. At some later
time
> you can pass Animal pointers that are actual Dog or Cat objects and access
> the appropriate methods of either. Also are you talking objects or
classes?

You tell me. An object is an instantiation of a class.

> Again I don't know how VB attempts this, but if you are talking about
implementing
> objects that are created by COM objects( by the References dialog in VB)
> then this is polymorphism because this is implementing VBTable binding( or
> Late depending on how the object was implemented), once again something
that
> VB programmers know nothing about.

You assume that VB programmers don't know a lot of things. How can you do
that? There are millions of VB programmers, you can't possibly know that
many? Just because VB is a high level language shielding its programmers
from the knitty-gritty of COM implementation does not conclude that they
don't know what a vtable binding is.

[Thomas Eyde]

Class Dog implementing the class Animal's interface is an Is-a relationship,
that is a Dog Is-an Animal. You may use a Dog where ever you can use an
Animal.Isn't that polymorphic?

/Thomas

"Ted" <TTarney@hotmail.com> wrote in message
news:3b1cd7c5$1@news.devx.com...
>
> By the way since this is a design group I will put it this way:
>
> A has-a relationship does not give polymorphic behavior. An Is-a does.

[Thomas Eyde]

That is a technical thing what we call it, isn't it? Isn't implementing an
interface in Java called "interface implementation"? I didn't know the
requirement for inheriting was to be able to extend.

I may remember wrong, but the arguments of polymorphism still apply.

/Thomas

"Craig Clearman" <chclear@nospam.please> wrote in message
news:1hmpht87llojatujvm1p22j5gsl8qnd08u@4ax.com...
> Thomas,
>
> >Looks like polymorphism to me. Of course this is a kind of inheritance,
we
> >are inheriting an interface.
>
> Actually, you are not. You are implementing an interface instead.
> Inheriting an interface would allow you to extend that interface,
> instead of supplementing it with an additional interface. Visual Basic
> doesn't allow you to inherit an interface natively.
>
> Ciao, Craig
>

[Ted]

Sorry, didn't intend to offend. I do know VB progammers, work with them,
live with one, but when it comes to deep down programming VB is just not
the same. I would say this is evident in the way that Microsoft has reimplemented
VB.NET.

Coincidentally, I did a little research with a colleague and he informed
me that every class in VB does have a VTable. So that pretty much explains
how VB gets away with polymorphism. VB has an implicit VPtr that I assume
VB programmers do not have to deal with or even know about. The whole concept
of a VTable to vb'ites is probably not known.

By the way, I would be willing to bet( and I will ask ) of the 12 or so VB
programmers here, 2 will know what Early, late and vtable binding is. Probably
because these 2 know COM very well.
"Thomas Eyde" <thomas.eyde@eunet.no> wrote:
>My comments inline.
>/Thomas
>
>"Ted" <TTarney@hotmail.com> wrote in message
>news:3b1cd770$1@news.devx.com...
>>
>> Doesn't sound like polymorphism to me at all. What you are talking about
>> is containment not inheritance. You know (at compile time) what type of
>> object you are dealing with.
>
>No. I did not talk about any implementation details. Just interfaces.
>
>> I do not know how VB attempts to handle polymorphism,
>> but once again that the original article was written in C++ I will coment
>> on polymorphism in a real OO language.
>
>I discussed polymorphism in COM. In C++ this obviously doesn't apply.
>Off topic: What is a real OO language anyway. If you apply the common
>criteria, no language will pass.
>
>> You have an Animal, and Dog and Cat inherit from Animal. At some later
>time
>> you can pass Animal pointers that are actual Dog or Cat objects and access
>> the appropriate methods of either. Also are you talking objects or
>classes?
>
>You tell me. An object is an instantiation of a class.
>
>> Again I don't know how VB attempts this, but if you are talking about
>implementing
>> objects that are created by COM objects( by the References dialog in VB)
>> then this is polymorphism because this is implementing VBTable binding(
or
>> Late depending on how the object was implemented), once again something
>that
>> VB programmers know nothing about.
>
>You assume that VB programmers don't know a lot of things. How can you do
>that? There are millions of VB programmers, you can't possibly know that
>many? Just because VB is a high level language shielding its programmers
>from the knitty-gritty of COM implementation does not conclude that they
>don't know what a vtable binding is.
>
>
>

[Craig Clearman]

Thomas,

>That is a technical thing what we call it, isn't it? Isn't implementing an
>interface in Java called "interface implementation"? I didn't know the
>requirement for inheriting was to be able to extend.

Yep.

>but the arguments of polymorphism still apply.

I agree.

Ciao, Craig