The Gist of Object Oriented Programming

[Jeff Schwab]

Do you honestly think that a vague and basically content-free statement like
this will serve to inform or sway anyone? I'm assuming you're planning to
address non-morons, and they're not likely to have a positive reaction to being
fed a contrived oversimplification. And if you are planning to address morons,
the best you can hope for is blank stare.

Claudio, you sweet talker! I disagree that this statement is "basically
content-free." There certainly is a limit to what will fit comfortably
into a line and a half of English text; I think the above sentence does
a decent first-pass at conveying the gist of OOP.

From the "Dictionary of Object Technology":

object-oriented programming (OOP):
(n) any application-specific programming resulting in programs that consist of
collections of collaborating objects which have a unique identity, encapsulate
properties and operations, communicate via message passing, and are instances
of classes related by inheritance, polymorphism, and dynamic binding [Booch,
Firesmith]

I'm not crazy about this definition for a few reasons (one being the use of the
term "message passing", another being the classification of dynamic binding as
a relation), but at least it has content and doesn't put the reader in a
catatonic state.

That same dictionary also has the following entry:

object-orientation (OO):
(adj) 1. (a) the paradigm that uses objects with identity that encapsulates
properties and operations, message passing, classes, inheritance, polymorphism,
and dynamic binding to develop solutions that model problem domains.
[Firesmith, Lorenz] (b) any technique based on the concepts of object, class,
instance, and inheritance. [Jacobson] 2. the use of objects as the atoms of
modeling. [Coleman]

Again, not ideal, but it conveys something meaningful.

No, those definitions convey almost nothing meaningful to someone who is
not already familiar with OOP. They define OOP in terms of its own
terms and artifacts. They may be a useful for philosophical discussions
among OOP experts, but they're certainly not a good way to get the
"gist" across to the uninitiated.

The "gist", as you put it,

I didn't choose that word, the OP did.

is that the shorter and more generalized you make
your statement, the more meaningless it will be. Meaningless slogans only work
if you're a politician or a third-rate marketeer trying to sell a commodity to
the lowest common denominator.

I don't believe it's a meaningless slogan. For the record, I have no
particular interest in pushing OOP or any other specific design technique.

 

[Daniel T.]

How much better? and better in what specific ways?

"How much better" is higly dependent on the problem being solved, some
problems lend themselves to an OO solution and can show a dramatic
reduction in code size (and its attendent increase in ease of
understanding and ease of modification,) while for others OO simply
isn't a tool that can be used. The primary way the code is better has
already been stated, reduction in code duplication. A little more
generally, OOP helps reduce what Brooks called "accedental complexity".

 

[Daniel T.]

Basically encapsulation can completely eliminate the problem of side-effects
in code maintenance. You chnage the internal workings of one class, and this
does not effect anything else, anywhere else. Besides this encapsulating
functionality and its required data into classes, can divide up a problem
so that solving a really big problem merely involves solving a few small
problems.

Functional programming completly eliminates the problem of side-effects,
OOP does not.

 

[Daniel T.]

On Tue, 20 Apr 2004 01:37:02 GMT in comp.lang.c++, "Peter Olcott"


Is that directed at me, or at Roger Smythe?

It's usenet, it's directed at anyone who cares to respond...

 

[Peter Olcott]

Is that directed at me, or at Roger Smythe?
Roger Smythe is my pseudonym

 

[Peter Olcott]

Basically encapsulation can completely eliminate the problem of side-effects

Functional programming completly eliminates the problem of side-effects,
OOP does not.

Because OOP provides the means to make every bit of all of the data
local to specific objects, whereas structured programming does not
provide this means, you are incorrect.

 

[Jeff Schwab]

Because OOP provides the means to make every bit of all of the data
local to specific objects, whereas structured programming does not
provide this means, you are incorrect.

Localizing state isn't the same thing as eliminating side effects. Any
method that changes the state of an object has a side effect.

Functional programming isn't the same thing as structured programming.
Functional programming really does eliminate side effects. Check out
the Haskell programming lanaguage.

 

[David Harmon]

On Tue, 20 Apr 2004 12:28:38 GMT in comp.lang.c++, "Peter Olcott"

Roger Smythe is my pseudonym

Well then, pass on to your pseudonym, the next time you hear from him,
the question
"Exactly which abstraction and concrete examples would be
most effective in making the point"
as that is apparently what you think he has to answer in order to write
the bit he expressed the desire to write. Only take into account that
your pseudonym seems to have a better grasp of one thing than you do:
OOP is not an alternative to structured programming. OOP goes together
with structured programming. OOP code in C++ should be structured as
much as any other kind of code.

The goal is to provide the gist of the benefits of OOP to structured
programmers in no more than a single short paragraph.

There is nothing in that, nor should there be, to suggest that anyone is
abandoning structure or that OOP is better than structure.

Perhaps it's time for your pseudonym to rejoin the discussion by posting
the revised version so far of his paragraph? I am sure that by now he
has gotten around to mentioning "inheritance" at least.

 

[David Harmon]

On Tue, 20 Apr 2004 07:23:23 -0400 in comp.lang.c++, Jeff Schwab

"A technique using elements of software to represent concepts, and the
ways those concepts relate to each other."

It might almost be more useful to shorten it to
"A technique."

I mean, as long as you are not going to say _which_ technique(s) and
what any of the benefits of those techniques are. (That is what we mean
by "content free".)

 

[Jeff Schwab]

On Tue, 20 Apr 2004 07:23:23 -0400 in comp.lang.c++, Jeff Schwab



It might almost be more useful to shorten it to
"A technique."

I mean, as long as you are not going to say _which_ technique(s) and
what any of the benefits of those techniques are. (That is what we mean
by "content free".)

I believe the essence of OOP is representing concepts and relationships
in software. I got that into a sentence. Explaining further would
require (I think) a lot more text.

 

[Jeff Schwab]

I believe the essence of OOP is representing concepts and relationships
in software. I got that into a sentence. Explaining further would
require (I think) a lot more text.

Before someone points out that the definition technically isn't a
sentence, please prefix it with "Object-oriented programming is."

 

[E. Robert Tisdale]

A means for the progressive decomposition a problem space into increasingly simpler component parts
such that these component parts represent higher levels of conceptual abstraction, and are
completely independent of each other except for their well-defined interfaces.

This was an attempt to explain the gist of OOP to programmers accustomed to the
structured programming paradigm. I tried to explain OOP in terms of ideals that can
be striven for, even though these ideals may never be perfectly achieved in real systems.

Does anyone have any ideas on how to improve this explanation?
The goal is to provide the gist of the benefits of OOP to structured
programmers in no more than a single short paragraph.

The phrase "objected oriented" was coined by Alan Kay

http://userpage.fu-berlin.de/~ram/pub/pub_isews26/doc_kay_oop_en
http://www.schipul.com/en/quotes/view.asp?quoteid=954

to describe his new programming language Smalltalk.
The first Object Oriented Programming language was Simula

http://heim.ifi.uio.no/~kristen/FORSKNINGSDOK_MAPPE/F_OO_start.html

The objects to which something is oriented are *data* objects.
The idea is that, when you call a function,
the function that is actually applied to the object
depends upon the *type* of the object.

In the stongest sense, this means that the object must be inspected
in real-time to determine the actual type of the object.
This is called variously "real-time polymorphism", "dynamic binding",
"dynamic dispatch", etc. The data object contains a tag
or a pointer to a virtual function table (jump table)
which depends only upon the actual type of the object.

More generally, the term "object oriented" is used
as a synonym for good programming practice.
If you ask an object oriented programmer to define object oriented.
they will probably begin by describing an Abstract Data Type (ADT)
so, evidently, for most object oriented programmers,
it is about implementing ADTs.
Note that C++ allows programmers to implement ADTs
that do *not* rely on real-time polymorphism.

 

[puppet_sock]

This was an attempt to explain the gist of OOP to programmers
accustomed to the
structured programming paradigm.
I tried to explain OOP in terms of ideals that can
be striven for, even though these ideals may never be
perfectly achieved in real systems.

[snip]

Instead of trying to capsulize a definition, why don't you actually
discuss the things that make OOP what it is? For example, talk about
things like encapsulation, abstraction, polymorphism, and inheritance.
Then talk about what those things do for the designer, what the
costs are, what some pitfalls are, etc. Then give some examples of
good OOP, and possibly some examples of bad OOP and why it's bad.

Generally, I'd go on the premise that the people who are comming
to you wanting to know "what is OOP?" are already of the opinion
that it is at least worth understanding. You don't need to do
any opinion creation or conversion of religions. I wouldn't bother
to try to boil it down to one or two sentences.
Socks

 

[Peter Olcott]

"How much better" is higly dependent on the problem being solved, some

problems lend themselves to an OO solution and can show a dramatic
reduction in code size (and its attendent increase in ease of
understanding and ease of modification,) while for others OO simply
isn't a tool that can be used. The primary way the code is better has
already been stated, reduction in code duplication. A little more
generally, OOP helps reduce what Brooks called "accedental complexity".

Although your first point is good, your second point is better.
The "accidental complexity" is reduced specifically because
an OOP language is capable of user defined data types that
much more closely correspond to the real world objects that
they are modeling. Also another crucial point of OOP is that
is can provide much better "black box" containment (typically
referred to as encapsulation). This can as much as completely
eliminate side-effects from changes made to code.

 

[Peter Olcott]

How about:

"A technique using elements of software to represent concepts from the
real world, and the ways those concepts relate to each other."

I like that. That does seem like an improvement some of what I said.
Let's see if I can improve your version a little more.

The means to create custom user defined data types to model real
world objects, with behavior and relationships that correspond
to their real world counter-parts.

 

[Peter Olcott]

"A technique using elements of software to represent concepts, and the

ways those concepts relate to each other."

No, the real-world is crucial. It provides the ready-made system design.

 

[Peter Olcott]

The "gist", as you put it, is that the shorter and more generalized you make

your statement, the more meaningless it will be. Meaningless slogans only work
if you're a politician or a third-rate marketeer trying to sell a commodity to
the lowest common denominator.

Claudio Puviani

The goal of this thread is to derive, not, a defitnion of OOP, but, the
most imporant benefits of OOP, to answer the question:
Why should I bother to learn OOP when I already am an expert in "C"?

The mechisms of OOP will never convince anyone. Only the benefits
will change minds. As it is it took management a full-decade to even
begin to seriously consider OOP. (1985 to 1995).

 

[Peter Olcott]

Instead of trying to capsulize a definition, why don't you actually

discuss the things that make OOP what it is? For example, talk about

Because I can't complete my sentence before the people walk off.
One must start with "what's in it for me" or one loses most of the
audience.

things like encapsulation, abstraction, polymorphism, and inheritance.
Then talk about what those things do for the designer, what the
costs are, what some pitfalls are, etc. Then give some examples of
good OOP, and possibly some examples of bad OOP and why it's bad.

Generally, I'd go on the premise that the people who are comming
to you wanting to know "what is OOP?" are already of the opinion

My target audience is those that have already decided that it is
not worth their time.

 

[Claudio Puviani]

The goal of this thread is to derive, not, a defitnion of OOP, but, the
most imporant benefits of OOP, to answer the question:
Why should I bother to learn OOP when I already am an expert in "C"?

The mechisms of OOP will never convince anyone. Only the benefits
will change minds. As it is it took management a full-decade to even
begin to seriously consider OOP. (1985 to 1995).

I don't know where you've been for the past 15-20 years, but minds have been
changed in vast numbers without there being a cutesy, amorphous slogan to sway
them. You may not be used to dealing with the professional programmers you
claim to want to address, but this is a crowd that's persuaded by technical
information, not by vague and nebulous statements of "benefits". They're smart
enough to figure out the potential benefits on their own if they're given
information instead of platitudes.

Claudio Puviani

 

[Claudio Puviani]

I like that. That does seem like an improvement some of what I said.
Let's see if I can improve your version a little more.

The means to create custom user defined data types to model real
world objects, with behavior and relationships that correspond
to their real world counter-parts.

It's generally accepted that, except in rare instance, trying to duplicate
"real world" objects in software is an almost sure recipe for disaster. It's
concepts that are modeled, and sometimes, the distillation of a real world
entity into its meaningful concepts leaves little of the original image. For
example, in systems programming, you don't model keyboard matrices and disks,
you model streams and file systems. To quote John Lakos, "modeling real world
objects leads to unwanted coupling and circular dependencies that turn testing
and maintenance into a nightmare, so we never do it" ('we' refering to software
engineers).

I doubt you'll find any books beyond the introductory level that condone
directly translating real world entities into software. The only place that's
still done is in the analysis phases where you're trying to model the domain,
not design the software.

Claudio Puviani