The Gist of Object Oriented Programming

[Roger Smythe]

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.

 

[David Harmon]

On Sun, 18 Apr 2004 17:23:16 GMT in comp.lang.c++, "Roger Smythe"

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 sentence no verb.

Does anyone have any ideas on how to improve this explanation?

Use shorter words. Use fewer words per sentence. Use active verbs.
Omit "a means for". Relate the abstract to the concrete.
Ask in alt.english.usage. Plagiarize Stroustrup, e.g. sect 1.7.

 

[Claudio Jolowicz]

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.

You describe OOP as a means for component-based programming and then
give a definition of the latter. Although it's certainly a good idea to
use OOP to decompose a program into components, OOP is not the only
"means" to do so. Also you don't specify what precisely the
object-oriented means are.

Why not introduce the concept of a class to convey what OOP is?
Essentially, a class (1) defines a scope, (2) provides information
hiding through access modifiers, and (3) constitutes a type that can be
multiply instantiated.

(This description skips over the OOP facilities for code reuse -
inheritance and aggregation.)

 

[Christopher Benson-Manica]

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.

Does anyone have any ideas on how to improve this explanation?

I bet the people on comp.object would have some.

http://www.slack.net/~shiva/welcome.txt
http://www.parashift.com/c++-faq-lite/

 

[Peter Olcott]

You describe OOP as a means for component-based programming and then
give a definition of the latter.

I intended the generic (common understood) meaning of the term component,
such as the component parts of which most all things tend to be comprised.

Although it's certainly a good idea to

use OOP to decompose a program into components, OOP is not the only
"means" to do so. Also you don't specify what precisely the
object-oriented means are.

It is not the means that I am focusing on , but, the benefits. The goal is
to sell the benefits of OOP as succinctly as possible.

Why not introduce the concept of a class to convey what OOP is?
Essentially, a class (1) defines a scope, (2) provides information
hiding through access modifiers, and (3) constitutes a type that can be
multiply instantiated.

I am only intending on selling the benefits, the means to these benefits
will never be seen by people that are not first sold on the benefits. It
is like I am answering the implicit question:

Why should I take all the time and effort to learn OOP when I already
know structured programming? I want to make it very clear, concise,
and persuasive so that even those many people whom have already decided
"its not worth the bother" will give it another look.

 

[Gary Labowitz]

interfaces.

I bet the people on comp.object would have some.

In addition to which you should have some notion of encapsulation
expressed in the explanation because it is key. Something like: "OOP
uses component parts which contain the data which makes them what they
are (properties) and code which provides how they function
(behaviors), encapsulated together and hidden from the users of those
components except through well-defined interfaces. A user has no
knowledge of the internal construction or working of each object. A
user only knows the interface and relies on it to provide
functionality from the object. This simplifies any later changes made
to the object in order to correct behaviors (fix bugs), improve
behaviors (speed up execution), or add new behaviors (maintain reverse
capability)."

Are those enough benefits for you?

 

[Claudio Puviani]

It is not the means that I am focusing on , but, the benefits. The goal is
to sell the benefits of OOP as succinctly as possible.

I am only intending on selling the benefits, the means to these benefits
will never be seen by people that are not first sold on the benefits. It
is like I am answering the implicit question:

Why should I take all the time and effort to learn OOP when I already
know structured programming? I want to make it very clear, concise,
and persuasive so that even those many people whom have already decided
"its not worth the bother" will give it another look.

I seriously doubt that phrasing a single sentence that tries to capture the
essence of OOP will sway anyone and it's likely going to come out sounding more
like someone preaching dogma, intoning a sales slogan, or trying to pencil in a
definition in an exam than like a serious argument.

Just explain the advantages point by point and be prepared to answer some tough
questions and to admit that OOP not only isn't the be-all-end-all of
programming, but that sometimes, it's not even the right way to approach a
problem. And if they're not interested in OOP, it's their right. It's just one
paradigm among many other valid ones.

Claudio Puviani

 

[osmium]

I seriously doubt that phrasing a single sentence that tries to capture the
essence of OOP will sway anyone and it's likely going to come out sounding more
like someone preaching dogma, intoning a sales slogan, or trying to pencil in a
definition in an exam than like a serious argument.

Just explain the advantages point by point and be prepared to answer some tough
questions and to admit that OOP not only isn't the be-all-end-all of
programming, but that sometimes, it's not even the right way to approach a
problem. And if they're not interested in OOP, it's their right. It's just one
paradigm among many other valid ones.

I totally agree. Einstein said something along the lines of ... make things
as simple as you can but no simpler. You are on the verge of sounding like
a salesman. When I hear something like "higher levels of conceptual
abstraction" I roll my eyes and get prepared for a snow job. I would
actually make a point that this is no silver bullet. Structured programming
*was* a silver bullet. This stuff is not even in the same ball park.

 

[Peter Olcott]

Just explain the advantages point by point
Exactly which advantages do you consider to be the most important?

My aim is to succinctly convey the most important advantages, not
in a single sentence, but in about one paragraph. I want to derive
a consensus opinion about the best way to answer the question:

Why should bother to take the time to learn a whole new way of
software development, when I already know structured programming?

and be prepared to answer some tough
questions and to admit that OOP not only isn't the be-all-end-all of

Its not intended to be a dialogue. What I am looking for is more
along the lines of an advertising slogan. Something that so quickly
and effectively makes its point there is not enough time to quit
reading before the point has already been made.

 

[Peter Olcott]

I totally agree. Einstein said something along the lines of ... make things

as simple as you can but no simpler. You are on the verge of sounding like
a salesman. When I hear something like "higher levels of conceptual
abstraction" I roll my eyes and get prepared for a snow job.

Yet this is precisely why programming has evolved over time from machine
language to assembly language, to third generation languages, and on. As
language levels rise (this itself is higher levels of conceptual abstraction)
far fewer instructions need be specified, and thus orders of magnitude
of programmer productivity arise.

 

[Daniel T.]

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.

Taking into account Mr. Olcott's critisisms, I'll try...

OOP gives the programer/designer the ability to remove more duplicated
code than structured programming does. This is something that every
programer can understand.

It is simply another tool that we can use to make our code better. Like
any tool, it is important to know how to use it, or its use may actually
cause more problems than it solves, none the less it is a tool that
every programmer should know how to use because its proper use makes for
better programs.

 

[Peter Olcott]

Taking into account Mr. Olcott's critisisms, I'll try...

OOP gives the programer/designer the ability to remove more duplicated
code than structured programming does. This is something that every
programer can understand.

It is simply another tool that we can use to make our code better. Like

How much better? and better in what specific ways?

 

[Peter Olcott]

Does anyone have any ideas on how to improve this explanation?

Use shorter words. Use fewer words per sentence. Use active verbs.
Omit "a means for". Relate the abstract to the concrete.

Exactly which abstraction and concrete examples would be
most efffective in making the point that OOP is better than
structured programming? Try to describe this so that structured
programmers can see for themselves how much better OOP is.

 

[Peter Olcott]

A means for the progressive decomposition a problem space into

increasingly simpler component parts

In addition to which you should have some notion of encapsulation
expressed in the explanation because it is key. Something like: "OOP

I agree,
"such that these component parts are completely
independent of each other except for their
well-defined interfaces"
was my attempt at emphasizing this without using unfamiliar term
(to structured programmers) of encapsulation.

uses component parts which contain the data which makes them what they
are (properties) and code which provides how they function
(behaviors), encapsulated together and hidden from the users of those
components except through well-defined interfaces. A user has no
knowledge of the internal construction or working of each object. A
user only knows the interface and relies on it to provide
functionality from the object. This simplifies any later changes made
to the object in order to correct behaviors (fix bugs), improve
behaviors (speed up execution), or add new behaviors (maintain reverse
capability)."

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.

 

[Jeff Schwab]

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.

How about:

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

 

[David Harmon]

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

Exactly which abstraction and concrete examples would be
most efffective in making the point that OOP is better than
structured programming? Try to describe this so that structured
programmers can see for themselves how much better OOP is.

Is that directed at me, or at Roger Smythe?

 

[David Harmon]

On Mon, 19 Apr 2004 22:57:27 -0400 in comp.lang.c++, Jeff Schwab

How about:

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

No, everybody does that, not just OOP. And probably best not to mention
"concepts from the real world" since that's not what OOP is about.
Unless you think e.g. iostreams or e.g. the Visitor pattern is a concept
from the real world.

 

[Jeff Schwab]

On Mon, 19 Apr 2004 22:57:27 -0400 in comp.lang.c++, Jeff Schwab



No, everybody does that, not just OOP. And probably best not to mention
"concepts from the real world" since that's not what OOP is about.
Unless you think e.g. iostreams or e.g. the Visitor pattern is a concept
from the real world.

I didn't say that OOP was the only technique serving this purpose.

You're right about removing the "real world" bit; it's not very
meaningful. Here's revised version:

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

 

[Claudio Puviani]

Here's revised version:

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

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.

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.

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

 

[Claudio Puviani]

object-orientation (OO):
(adj) ...

I scanned a few lines too far while copying and took the "adj" from the
"object-oriented" entry. Obviously, "object orientation" is a noun, not an
adjective.

Claudio Puviani