From: Rob Thorpe on
Peter Seibel wrote:
> "Rob Thorpe" <robert.thorpe(a)antenova.com> writes:
>
> > The textbooks I refer to certainly aren't lame since they use the
> > normally accepted defintion of OO - ie. that written in most books and
> > used by most programmers. I have never read a book that ties OO to
> > polymorphism as you have tried to, but I would be interested to know if
> > such a misleading text exists.
>
> Hmmm. What is this "normally accepted definition of OO" of which you
> speak? Anyway, for such a misleading text, try:
>
> <http://www.gigamonkeys.com/book/>
>
> in particular Chapter 16:
>
> <http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html>

Nice book, I had no idea it was available online, that's very useful.

Christer Ericson has already made most of the important points, at
least as well as I could have done.

The difference between our viewpoints occurs when a program makes use
of structures that encapsulate data and code together hiding the data's
representation do not go as far as using polymorphism. I think you
would call the structures in such a program ADTs whereas I would call
them objects. (This is really only a small change in nomenclature).

I use this definition for three reasons:
1) A great number of books use the same definition, such as those in
the list Christer gives
2) Many programmers I have met use that definition
3) It is useful in talking to people about the code

What I mean by (3) is that the step change in difficulty in
understanding a program comes when the program is structured as above.
Once data and code are encapsulated the program is much different than
it would be if it were a procedural program. To someone who only
understands procedural programs it would be difficult to understand.
Whereas there's no step-change in understanding needed to comprehend
virtual methods or indeed inheritance.

Although this is only a small change in nomenclature it is an important
one. For instance the (horrible) Windows API uses what I would
consider object-orientation, through RegisterClassEx, CreateWindow etc.
But it doesn't really support polymorphism.

From: Phlip on
Rob Thorpe wrote:

> Although this is only a small change in nomenclature it is an important
> one. For instance the (horrible) Windows API uses what I would
> consider object-orientation, through RegisterClassEx, CreateWindow etc.
> But it doesn't really support polymorphism.

The Window Procedure bound to each window, to handle its messages, isn't
polymorphic?

(About "horrible", farbeit from me to defend Microsoft, but I'd like to see
/you/ invent an event-driven windowing system that can bind to a wide range
of non-OO languages...)

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand


From: Phlip on
Rob Thorpe wrote:

> Yes. I was saying that it's not necessary to have data and code bound
> at runtime to have object. It could be done at compile time.

Is this C code "object oriented"?

void operation(struct object * pObject);

It binds data (struct object) with code (operation()) at compile time.

Or would the dot notation aObject.operation() make it object oriented?

> What does the Liskov substitution principle have to do with anything?

If you declare "An OO language must support LSP", that implies an OO
language must support polymorphism. Otherwise either nothing can substitute,
or the caller must remain aware which substitution occurs.

--
Phlip
http://www.c2.com/cgi/wiki?ZeekLand


From: Rob Thorpe on
Phlip wrote:
> Rob Thorpe wrote:
>
> > Although this is only a small change in nomenclature it is an important
> > one. For instance the (horrible) Windows API uses what I would
> > consider object-orientation, through RegisterClassEx, CreateWindow etc.
> > But it doesn't really support polymorphism.
>
> The Window Procedure bound to each window, to handle its messages, isn't
> polymorphic?

You're right, I'm wrong. I appear to have left my brain at home today.

> (About "horrible", farbeit from me to defend Microsoft, but I'd like to see
> /you/ invent an event-driven windowing system that can bind to a wide range
> of non-OO languages...)

True. There could be less unnecessarily weird detail though, like
returning true and false opposite ways around for processing dialog
messages and processing normal message loops. Anyway I won't try to
write anything better today while my brain is at home.

From: topmind on
> Since OO is NOT about either inheritance trees or polymorphism,
> developers who use neither may still be using OO.

I didn't really mean it that way. What I meant was that developers
tend to use procedural techniques wrapped in classes. But this does get
into the issue of what the definition of OO really is, and that
question has no consensus answer.

-T-

First  |  Prev  |  Next  |  Last
Pages: 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
Next: Use Case Point Estimation