What do you think the single most important feature of OO is?
Thomas Gagné
To access the methods of an object, we use the same syntax as
accessing the data of an object... This is why it is called
"object-oriented programming; the object is the focus here, not the
functional call. This is probably the single most important feature
of the object-oriented paradigm."
Do you agree, or are there equally important and fundamental features
without which OO programming would cease to be OO?
--
.tom
remove email address' dashes for replies
opensource middleware at <http://isectd.sourceforge.net>
http://gagne.homedns.org
Myles
"Thomas Gagné" <tga...@wide-open-west.com> wrote in message
news:3F2E76B9...@wide-open-west.com...
> I was recently reading "Java in a Nutshell" and came across this
statement:
>
> To access the methods of an object, we use the same syntax as
> accessing the data of an object... This is why it is called
> "object-oriented programming; the object is the focus here, not the
> functional call. This is probably the single most important feature
> of the object-oriented paradigm."
>
> Do you agree, or are there equally important and fundamental features
> without which OO programming would cease to be OO?
Are you sure you didn't leave out something important in the ... ? Is the
author actually claiming that a detail of syntax is fundamental to OO?
Smalltalk and Perl are two languages adapted for OOP that do not conform to
the above statement, and I'm sure there are others.
M.
Thomas Gagné
object rather than calling a function with the circle object passed as a
parameter. The author WAS NOT indicating the syntax was the important
thing, but rather the concept of sending methods to objects rather than
sending objects to methods. That the object is the important
programming atom and not the function call.
From the text:
To access the methods of an object, we use the same syntax as
accessing the data of an object:
Circle c = new Circle();
doube a;
c.r = 2.5;
a = c.area()
Take a look at the last line. We did not say:
a = area(c)
We said:
a = c.area()
This is why it is called "object-oriented" programming;...
Myles wrote:
>
>Are you sure you didn't leave out something important in the ... ? Is the
>author actually claiming that a detail of syntax is fundamental to OO?
>
>Smalltalk and Perl are two languages adapted for OOP that do not conform to
>the above statement, and I'm sure there are others.
>
>
--
Thaddeus L Olczyk
OO" except for one.
The single most negative feature of OO is that it attracts idiots who
ask questions like: "What do you think the single most important
feature of OO is?"
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
Thomas Gagné
>I'm not ready to make any kind of value judgements about "features of
>OO" except for one.
>
>The single most negative feature of OO is that it attracts idiots who
>ask questions like: "What do you think the single most important
>feature of OO is?"
>
Good point.
I'm wondering if a Maslow-like pyramid might be described listing what
those features might be in order of importance so that multiple OOPLs
could be listed side-by-side showing how different OOPLs provided for
varying "needs" of the OO paradigm. I thought the Nutshell statement
was a strong one and thought others, like yourself, may have similarly
strong statements they may be willing to make--except of course that the
poster is an idiot.
Some might feel inheritence is more salient than whether methods were
endomatic or exomatic. Some may think class hierarchies are a defining
characteristic of OO paradigms or that OO wouldn't be OO without data
being composed with methods--and that objects without specific behavior
simply aren't objects at all.
E. Robert Tisdale
> In the elipse was an example of sending the method area() to a circle
> object rather than calling a function with the circle object passed as a
> parameter. The author WAS NOT indicating the syntax was the important
> thing, but rather the concept of sending methods to objects rather than
> sending objects to methods. That the object is the important
> programming atom and not the function call.
> From the text:
>
> To access the methods of an object, we use the same syntax as
> accessing the data of an object:
>
> Circle c = new Circle();
> doube a;
> c.r = 2.5;
> a = c.area()
>
> Take a look at the last line. We did not say:
>
> a = area(c)
> We said:
> a = c.area()
>
> This is why it is called "object-oriented" programming;...
This is nonsense.
Return this book to the bookstore where you got it
and demand your money back.
Thant Tessman
[...]
> Some might feel inheritence is more salient than whether methods were
> endomatic or exomatic. Some may think class hierarchies are a defining
> characteristic of OO paradigms or that OO wouldn't be OO without data
> being composed with methods--and that objects without specific behavior
> simply aren't objects at all.
OO is like the Bible in that which scripture is to be interpreted
metaphorically, and which is to be interpreted literally, is entirely a
function of the religious agenda of the commentator. My own advice is to
keep in mind that the stuff of computer programs is nothing but metaphor.
-thant
Thomas Gagné
>
> OO is like the Bible in that which scripture is to be interpreted
> metaphorically, and which is to be interpreted literally, is entirely
> a function of the religious agenda of the commentator. My own advice
> is to keep in mind that the stuff of computer programs is nothing but
> metaphor.
That might be true.
If that is the case then there would be no objective criteria to
evaluate competing technologies on their ability to provide the
constructs necessary to write OO code more, sall we say, naturally, than
other languages. There would be no benefit to the OOD being written in
Java than in COBOL.
E. Robert Tisdale
> I'm wondering if a Maslow-like pyramid might be described listing what
> those features might be in order of importance so that multiple OOPLs
> could be listed side-by-side showing how different OOPLs provided for
> varying "needs" of the OO paradigm. I thought the Nutshell statement
> was a strong one and thought others, like yourself, may have similarly
> strong statements they may be willing to make--except of course that the
> poster is an idiot.
>
> Some might feel inheritance is more salient than whether methods were
> endomatic or exomatic. Some may think class hierarchies are a defining
> characteristic of OO paradigms or that OO wouldn't be OO without data
> being composed with methods--and that objects without specific behavior
> simply aren't objects at all.
According to Bjarne Stroustrup,
"Why C++ is not just an Object-Oriented Programming Language",
Addendum to OOPSLA95 Proceedings, ACM OOPS Messenger, October 1995
http://www.research.att.com/~bs/oopsla.pdf
"A language or technique is object-oriented
if and only if it directly supports:
[1] Abstraction - providing some form of classes and objects.
[2] Inheritance - providing the ability to build new abstractions
out of existing ones.
[3] Run-time polymorphism - providing some form of run-time binding.
This definition includes all major languages
commonly referred to as object-oriented:
Ada95, Beta, C++, CLOS, Eiffel, Simula, Smalltalk,
and many other languages fit this definition."
The set of features used to distinguish so-called
Object Oriented Programming Languages from all other
computer programming languages is *not* unique.
Other experts may cite different sets of discriminating features.
For most Object Oriented Programmers, Object Oriented Programming
is about implementing Abstract Data Types (ADTs).
See "Data Structures and Algorithms" by Aho, Hopcroft and Ullman.
An ADT defines
1. the set of values that an object of a type can have and
2. all of the methods that may be applied to an object of that type.
I submit that your interpretation of OOP is similar.
When Alan Kay coined the term "object oriented",
he was attempting to describe smalltalk
and *not* trying to classify computer programming languages.
For Alan Kay, the key feature of smalltalk was "messaging"
which Bjarne Stroustrup calls run-time polymorphism.
Would computer programmers have made such a fuss if Alan Kay
had coined "message oriented" instead of "object oriented"?
Probably not.
Run-time polymorphism is an important feature of OOP
but it isn't the "big idea".
The "big idea" is a change in focus in popular computer
programming languages over the last two decades
away from algorithmic abstraction
(Procedure Oriented Programming (POP) if you like)
toward data abstraction -- OOP.
H. S. Lahman
> I was recently reading "Java in a Nutshell" and came across this statement:
>
> To access the methods of an object, we use the same syntax as
> accessing the data of an object... This is why it is called
> "object-oriented programming; the object is the focus here, not the
> functional call. This is probably the single most important feature
> of the object-oriented paradigm."
>
> Do you agree, or are there equally important and fundamental features
> without which OO programming would cease to be OO?
I agree it is a core characteristic. But I would rank abstraction as
more important. I would also rank encapsulation, implementation hiding,
and peer-to-peer collaboration as being of comparable importance.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindersol.com
Pathfinder Solutions -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH
Thant Tessman
> Thant Tessman wrote:
>
>>
>> OO is like the Bible in that which scripture is to be interpreted
>> metaphorically, and which is to be interpreted literally, is entirely
>> a function of the religious agenda of the commentator. My own advice
>> is to keep in mind that the stuff of computer programs is nothing but
>> metaphor.
>
>
> That might be true.
>
> If that is the case then there would be no objective criteria to
> evaluate competing technologies on their ability to provide the
> constructs necessary to write OO code more, sall we say, naturally, than
> other languages. There would be no benefit to the OOD being written in
> Java than in COBOL.
I need to be more careful. That's not what I meant at all.
We invent our abstractions to manage complexity. We name our
abstractions to manage them. Arguing about what is and is not OO is
nowhere near as important as trying to understand when and if features
facilitate abstractions that are well-chosen for the task at hand.
-thant
Thomas Gagné
me busy. His comments warning against making 'object-oriented'
meaningless through unnecessary implications of good v. bad or being
associated with a single language are well taken.
E. Robert Tisdale wrote:
> According to Bjarne Stroustrup,
> "Why C++ is not just an Object-Oriented Programming Language",
> Addendum to OOPSLA95 Proceedings, ACM OOPS Messenger, October 1995
>
> http://www.research.att.com/~bs/oopsla.pdf
>
> <snip>
Thomas Gagné
>
> I need to be more careful. That's not what I meant at all.
>
> We invent our abstractions to manage complexity. We name our
> abstractions to manage them. Arguing about what is and is not OO is
> nowhere near as important as trying to understand when and if features
> facilitate abstractions that are well-chosen for the task at hand.
>
Those seem to be (approximately) Stroustrup's thoughts as well.
Shane Mingins
hope) the single most important feature of it to be ... and at the end of
the day I related it back to the two most important things to me as a
programmer .... it must allow me to develop software quickly and allow me to
extend (or maintain) software quickly.
Is that view perhaps too simplistic?
Shane
--
shanem...@yahoo.com.clothes
remove clothes before replying
"What are you famous for?" she asked.
"I am simply famous," he replied.
"Thomas Gagné" <tga...@wide-open-west.com> wrote in message
news:3F2E76B9...@wide-open-west.com...
E. Robert Tisdale
> Thant Tessman wrote:
>
>> OO is like the Bible
>> in that which scripture is to be interpreted metaphorically,
>> and which is to be interpreted literally, is entirely
>> a function of the religious agenda of the commentator.
>> My own advice is to keep in mind that
>> the stuff of computer programs is nothing but metaphor.
Amen.
> That might be true.
>
> If that is the case, then there would be no objective criteria
> to evaluate competing technologies on their ability to provide
> the constructs necessary to write OO code
> more, sall we say, naturally, than other languages.
> There would be no benefit
> to the OOD being written in Java [rather] than in COBOL.
Despite all of the benefits claimed for OOP,
there are, to my knowledge, no objective tests
or comparative scientific studies
that bear out any of these claims.
Dave Harris
(abridged):
> [from "Java in a Nutshell"]
> To access the methods of an object, we use the same syntax as
> accessing the data of an object... This is why it is called
> "object-oriented programming; the object is the focus here, not the
> functional call. This is probably the single most important feature
> of the object-oriented paradigm."
This isn't clear out of context; perhaps it means the implementation of
the feature is hidden. A clumsy way of introducing abstract data types.
> Do you agree, or are there equally important and fundamental features
> without which OO programming would cease to be OO?
Abstract data types are most important. Also important are message-sending
or some other kind of dynamic polymorphism (eg multi-methods); and
inheritance or some other kind of explicit reuse mechanism (eg
delegation).
I first saw this list in an old issue of "Byte". It echoes almost exactly
what Stroustrup is quoted as saying elsewhere in this thread.
-- Dave Harris, Nottingham, UK
JXStern
<E.Robert...@jpl.nasa.gov> wrote:
>When Alan Kay coined the term "object oriented",
>he was attempting to describe smalltalk
>and *not* trying to classify computer programming languages.
>For Alan Kay, the key feature of smalltalk was "messaging"
>which Bjarne Stroustrup calls run-time polymorphism.
Agree that in Smalltalk (and at that time) the focus was on messaging,
but that assumes from the earlier Simula the idea of classes as even
more basic. What is a class? An intuitive, or a real-world, or a
set-theory, logical entity, as the case may be, with luck all of the
above.
The messaging paradigm offered loose coupling and/or late binding as
well, both of which were very nearly lost in the move to C++. With
languages like Python these features have now come back.
I do not think that equating Kay's messaging and Stroustrup's run-time
polymorphism is entirely valid, but that's an old debate.
Joshua Stern
Myles
"E. Robert Tisdale" <E.Robert...@jpl.nasa.gov> wrote in message
news:3F2E8BF6...@jpl.nasa.gov...
> Thomas Gagné wrote:
> > From the text:
> > To access the methods of an object, we use the same syntax as
> > accessing the data of an object:
> >
> > Circle c = new Circle();
> > doube a;
> > c.r = 2.5;
> > a = c.area()
> >
> > Take a look at the last line. We did not say:
> >
> > a = area(c)
> > We said:
> > a = c.area()
> >
> > This is why it is called "object-oriented" programming;...
>
> This is nonsense.
> Return this book to the bookstore where you got it
> and demand your money back.
With that context (which was important), it makes perfect sense to me.
In the first syntax, "area" is owned by the executable. In the second, it's
owned by the object (or by the class, which provides it to each object). I
agree that the binding of code to instances is fundamental to OO.
M.
Thomas Gagné
>>With that context (which was important), it makes perfect sense to me.
>>In the first syntax, "area" is owned by the executable. In the second, it's
>>owned by the object (or by the class, which provides it to each object). I
>>agree that the binding of code to instances is fundamental to OO.
>>
That would appear to support Stroustrup's suggestion that object
oriented programming promotes data abstraction over the (then) prevalent
procedural abstraction.
I had never thought of what I was doing in procedural languages as
procedural abstraction, but looking back it makes sense.
Back on topic, it's important to note how many fewer details are
required in the data abstracted code than in the procedurally abstracted
code. What must be done is the same and it could be argued the number
of lines is the same, but the responsibility and therefor the potential
for error is reduced when the consumer of c.area() (another programmer)
doesn't need to know the formula, its use of the radius, the need for
pi, or the type of the arguments.
From this standpoint we might be able to generate some objective
statistics--but that's not the point of my question. I'd first like to
be able to measure the object-orientedness of various languages, even
those that are multi-paradigm. A language wouldn't get marked-down for
supporting multiple paradigms, but might be dented for only partial
support for object-orientedness.
The thought is still developing. I may instead just write an essay on a
related topic.
Universe
> Myles wrote:
>>>With that context (which was important), it makes perfect sense to me.
>>>In the first syntax, "area" is owned by the executable. In the second, it's
>>>owned by the object (or by the class, which provides it to each object). I
>>>agree that the binding of code to instances is fundamental to OO.
> That would appear to support Stroustrup's suggestion that object
> oriented programming promotes data abstraction over the (then) prevalent
> procedural abstraction.
Yes, yes, yes, yes, YEEEESSSSSSS!!!!!
:-}
Elliott
Universe
> Thomas Gagné wrote:
>> Myles wrote:
> :-}
But *NOT* data, data.
It promotes entities with data properties *RESPONSIBLE* for doing things
versus 3GL where verb functions/routines/procedures/etc are promoted over
object-oriented's responsible *noun* approach.
That OO is about encapsulating data is one of the worst damnable lies
floating around in the OO space.
Elliott
--
OO software rests upon class abstractions expressed in class method
*behaviors*. The sum of class method behaviors is the overall class
*role*. Class role should have primary responsibility for managing class
data such that the impact of class data is driven by the operation of
class methods.
~*~ Get with OO fundamentals, get OO. ~*~
-
We Don't Need US Fat Cat's Geopolitical Hegemony!
People of the World Demand US Stop Now!
-
* http:\\www.radix.net/~universe *
@Elliott 2003 my comments ~ newsgroups+bitnet OK
E. Robert Tisdale
> But *NOT* data, data.
>
> It promotes entities
> with data properties *RESPONSIBLE* for doing things
> versus 3GL where verb functions/routines/procedures/etc.
imperatives
> are promoted over object-oriented's responsible *noun* approach.
>
> That OO is about encapsulating data [exclusively]
> is one of the worst damnable lies floating around in the OO space.
Evidently, you are saying that Object Oriented [Programming]
Universe
> Elliot wrote:
> imperatives
Doesn't seem that way to me, but ahhh....
Universe
> Elliot wrote:
>>
>> That OO is about encapsulating data [exclusively]
>> is one of the worst damnable lies floating around in the OO space.
Nope, here's what *I* *actually* wrote:
"That OO is about encapsulating data is one of the worst damnable lies
floating around in the OO space."
Ahhh... And I meant what *just* what *I* wrote.
Universe
> Elliot wrote:
>> But *NOT* data, data.
>>
>> It promotes entities
>> with data properties *RESPONSIBLE* for doing things
>> versus 3GL where verb functions/routines/procedures/etc.
> imperatives
>> are promoted over object-oriented's responsible *noun* approach.
>>
>> That OO is about encapsulating data
>> is one of the worst damnable lies floating around in the OO space.
> Evidently, you are saying that Object Oriented [Programming]
> is about implementing Abstract Data Types (ADTs).
Hmmm... your logic escapes me. Perhaps more see this by me:
"OO software rests upon class abstractions expressed in class method
*behaviors*. The sum of class method behaviors is the overall class
*role*. Class role should have primary responsibility for managing class
data such that the impact of class data is driven by the operation of
class methods. Get with OO fundamentals, get OO."
Topmind
>
> > I was recently reading "Java in a Nutshell" and came across this statement:
> >
> > To access the methods of an object, we use the same syntax as
> > accessing the data of an object... This is why it is called
> > "object-oriented programming; the object is the focus here, not the
> > functional call. This is probably the single most important feature
> > of the object-oriented paradigm."
> >
> > Do you agree, or are there equally important and fundamental features
> > without which OO programming would cease to be OO?
>
> I agree it is a core characteristic. But I would rank abstraction as
> more important. I would also rank encapsulation, implementation hiding,
> and peer-to-peer collaboration as being of comparable importance.
>
Um, "abstraction" is a rather fuzzy concept to use in definitions.
I think relational algebra is a grand abstraction, BTW.
These "what is OO really about" discussions never end on a concensus
anyhow. Universe knows this, for he has participated in
various definition fights before.
-T-
Wzeigler
Most developers tend to think in the bits and bytes layer of things, but when
trying to teach procedural developers what OO is, such explinations almost
always lead the them asking "Why do that? So what?"
I have found that, at least to this group, the most important and enlightening
area do emphasise is that, in the final design, the critical element is the
interaction of the objects. This makes the bits and bytes explinations details,
but gives reason to their existence.
Warren Zeigler