Talk About Network

Google


Register and Login
Nick
Password
Register create new account Sign up is FREE and you can post replies, new topics, bookmark posts and more!
Recover lost password


Programming > Languages Misc > Re: Reasoning a...
Latest [ Topics | Posts ] Archive Post A New Topic Post a Reply
<< Topic < Post Post 2 of 3 Topic 1064 of 1217
Post > Topic >>

Re: Reasoning about OOP

by Logan Shaw <lshaw-usenet@[EMAIL PROTECTED] > Oct 28, 2007 at 04:13 PM

thomas.mertes@[EMAIL PROTECTED]
 wrote:
> Hello, I did some reasoning about OOP and it's advantages.
> 
> A lot of OOP fans say that "OOP is closer to our way of
> thinking". This might be the case when you always used
> classical OOP languages...  Such argumentations can be
> summarized as: OOP is great because OOP is great...

That's only one interpretation of the argument.  However, even
though the argument may not always be posed clearly, I don't
think it's totally fair to dismiss it as semantically empty,
a tautology, or whatever.

The interpretation I've always taken, which is a bit different,
is that human beings naturally organize thoughts around abstractions.
The human mind, it can be argued, finds it convenient to have a place
to put ideas.  It wants to associate ideas with a certain context.
I would argue that the human mind tends to, among other things,
organize thoughts around an abstraction called "the object".

I have an electric toothbrush.  Actually, it's just some plastic,
some metal, some chemicals contained in a cell, a switch, some
more stringy plastic (which we call bristles), that all happens
to be arranged a certain way.  I just call it an "electric
toothbrush" because I heard other people doing that.  But I
still see the various materials in that configuration, and it
calls to mind certain things.  I think of the name "electric
toothbrush".  I think of some properties that it has, like that
I can use it to clean my teeth, that it needs to be recharged
to do that, that it should be cleaned, that it's heavy and I
could throw it at someone to defend myself in a pinch.

I put all these thoughts together in my mind under the heading
"electric toothbrush".  If I do not ponder it very much, I may
leave them there.  If I do ponder it, I may refine my views and
I may realize that I can clean my teeth by rubbing toothpaste
around with my finger if necessary, and I may realize that I
could use the toothbrush as a musical instrument (because it
buzzes at a certain pitch).  But the default state and the
easiest state to get to mentally is to grab hold of the idea
that it is an object, it is certain things, and it does certain
things, and leave it there.

I am not arguing that lumping things into categories is always
the best and most flexible way to think.  Indeed, we've all
gotten annoyed at people for inflexible thinking.  A favorite
example of mine is the term "digital film" for flash memory.
But that inflexible thinking just serves to illustrate that
people often think in terms of objects and types of objects.

So while it's not the ultimate solution that helps us organize
all our thoughts perfectly, I do think object-oriented programming
does to some extent mirror the way we often think.

> When there is only one implementation you can omit the
> interface. Then it is not really OOP any more.

I am not sure I agree that allowing one to substitute in
one implementation for another without changing the interface
is an absolutely essential part of object-oriented programming.
I agree it's often useful, but I think you could write a
program and call it "object-oriented" without ever separating
interface and implementation.

> IMHO interfaces make only sense when there
> are several implementations.

Personally, I find them to be a valuable tool to help me focus
my thoughts on what I'm doing.  I like typing up an interface to
be a separate process from typing out the implementation because
it allows me to say "right now, I am defining the interface" or
"right now, I am making the implementation".  It not absolutely
essential, but I think a clear delineation between the two serves
as a helpful reminder of what you're doing and can lead to a better
thought process and a better design.

> Container librarys are often seen as advantages of OOP, but
> they have nothing to do with OOP. Typical OOP containers have
> no type checking for the elements.

Two comments.  First, to me, type *checking* is pretty much
an orthogonal concept to object orientation.  You can have
neither, or you can have both, or you can have either one
without the other.  Type-checking becomes a little more
involved when you are working with an OOP type system, but
that's about the only connection I see.

Second, one goal often associated with OOP is widespread code
reuse.  Container libraries are often examples of successful
code reuse.  So in that sense, they are related.  But it is
a weak relation****p, because one can easily make a reusable
container library without any OO aspects at all.

> IMHO it is better to come back to a symetrical situation.
> The cl***** of all parameters together decide which implementation
> is used. For long time OOP proponents this sounds strange, but
> it is a more natural approach. This concept is called multiple
> dispatch. When multiple dispatch is used some things change:
> Methods do not belong to a class any more. Instead the methods
> are "between" the cl*****. There is no 'this' of 'self' any more.
> Instead there are just normal parameters. But how can you do this?

It seems to me (and of course there are lots of opinions on this)
that multiple dispatch has both positives and negatives.  It is
simpler and less complicated to view the world in a way where methods
belong to a single class.  The class can stand on its own and there
are fewer things to consider at one time.  But it's also less flexible.

If you need the flexibility for some reason, multiple dispatch may
make sense.  It can definitely be more aesthetically pleasing in
certain cases.

However, one of the other negatives is the ambiguity involved
when deciding what method to dispatch if two or more parameters'
types involve inheritance.  Some sort of arbitrary rule has to be
made.  And worse, although I have not used multiple dispatch very
much, it seems like resolving ambiguities can only be done in a
global context where an arbitrarily-large number of hierarchies
of cl***** may be involved.  In the worst case, that seems like
it would sometimes make it difficult to combine together various
software components and see what the effects are going to be.
So that negative would have to be outweighed by other positives
for me to want to use it.

   - Logan
 




 3 Posts in Topic:
Reasoning about OOP
thomas.mertes@[EMAIL PROT  2007-10-28 12:58:39 
Re: Reasoning about OOP
Logan Shaw <lshaw-usen  2007-10-28 16:13:35 
Re: Reasoning about OOP
"cr88192" <c  2007-10-29 13:04:05 

Post A Reply:
  Go here to Signup

AddThis Feed Button


About - Advertising - Contact - Frequently Asked Questions - Privacy Policy - Terms of Use - Signup

Contact
tan12V112 Fri Jul 25 17:55:37 CDT 2008.