The Gist of Object Oriented Programming

[Jeff Schwab]

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.

That's not bad, if your target audience already understands what data
types are.

 

[Mark A. Gibbs]

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.

Not that I disagree with your point, nor do I have anything against you
personally Mr. Puviani, but you must not be used to dealing with people.
For sure a rational and objective discussion will convince a group of
knowlegable and open-minded people. But those kinds of people are very
rare. More often you'll get people that are looking for easy solutions -
consciously or otherwise - either programmers looking to do less work or
managers looking to increase "productivity". In the rare case that I
have encountered somebody willing and eager to do real work, they are
either uninterested in learning or unable to grasp the deeper issues
behind a topic at first.

Programmers are no less susceptible to hype than the general populace.
If anything, they're probably just more wary of it simply because
there's so much of it in this field, and they've either been burned many
times or have seen too many others burned.

Besides, it is a lot easier to memorize a 3 sentence paragraph than an
entire book, but if you can relate the entire book to that 3 sentence
paragraph, you're well on your way to memorizing the book.

I don't doubt that a platitude will satisfy far more people than it will
annoy. History and statistics are on my side there. The only issues for
a responsible mass-market educator, then, become finding a good
"executive summary" or catchphrase, and clearly conveying to the
audience the highlights and limitations of it by demonstrating it
action. By that metric, the OP is off to a good start by coming here
(well, maybe not specifically *here*) and asking for help.

If you or some of the other posters in this thread are the type that
gets annoyed by "executive briefs" such as the OP's, that's fine - it
tells me that you've moved on to a more critical stance on OO, which is
obviously a step up from blind acceptance of application of dogma, which
is Good. But chastising those that have not reached that stage (ie, the
"lowest common denominator"), or those attempting to reach an audience
not yet there (ie, "politician"s or "third-rate marketeer"s), benefits
no-one. I cannot see it would improve the comp.lang.c++ community either.

And for the record, I disagree with Jeff Schwab's criticism of defining
of OO using its own terms. Presumably, shortly after you give the
definition, you define the terms (in the process of explaining OO). And
when you are done, you can reiterate the original definition with the
(now charged) terms. Now the "platitude" becomes a checklist of the most
important concepts and mechanisms in OO. I would recommend that to the OP.

mark

 

[Jeff Schwab]

And for the record, I disagree with Jeff Schwab's criticism of defining
of OO using its own terms. Presumably, shortly after you give the
definition, you define the terms (in the process of explaining OO). And
when you are done, you can reiterate the original definition with the
(now charged) terms. Now the "platitude" becomes a checklist of the most
important concepts and mechanisms in OO. I would recommend that to the OP.

If the effort is to gain the reader's interest as quickly as possible,
why do you think he or she will keep reading past an opening sentence
full of unfamiliar and as-yet meaningless technical terms?

 

[Daniel T.]

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.

You might want to look into Functional (not structured) programming
before continuing with this...

 

[Peter Olcott]

Functional programming completly eliminates the problem of side-effects,

You might want to look into Functional (not structured) programming
before continuing with this...

So somebody overloaded the term "functional programming" to mean
something other than {functional decomposition}? I would consider this
an error if they did. Just like the error of the term "worthless" meaning
something other than {worth less}. Something that is "worthless" is not
{worth less} it is {worth nothing}. I consider this to be an error by
whomever starting this term.

 

[Peter Olcott]

If the effort is to gain the reader's interest as quickly as possible,

why do you think he or she will keep reading past an opening sentence
full of unfamiliar and as-yet meaningless technical terms?

Right!

 

[Mark A. Gibbs]

If the effort is to gain the reader's interest as quickly as possible,
why do you think he or she will keep reading past an opening sentence
full of unfamiliar and as-yet meaningless technical terms?

I would assume that they are reading that sentence because they intend
to learn what object-oriented programming is. And the idea isn't to gain
the reader's interest, it's to acquaint them with the concepts.

In essence, what I'm suggesting is laying out a roadmap for the lesson -
a lesson outline, if you prefer - then following that with the lesson
itself, then showing how the lesson followed the plan to paint the whole
picture. It's a classic education strategy. What you're asking me is why
I think a student will continue the course after seeing the lesson outline.

If a student can't get past the lesson outline, they're pretty much a
lost cause to me (but maybe a real teacher would still give it a go).

Do you seriously think that a student would gain more from an abstract
theoretical discussion of the implications of concepts they are just
being introduced to? Do you think that a person incapable of getting
through a brief introduction - that contains a few terms they will
shortly be introduced to - would stand a better chance of making it
through that?

mark

 

[Jeff Schwab]

I would assume that they are reading that sentence because they intend
to learn what object-oriented programming is. And the idea isn't to gain
the reader's interest, it's to acquaint them with the concepts.

I haven't assumed anything about the reader's motivation. Depending on
context, then, either of our approaches might be more appropriate.

 

[Claudio Puviani]

So somebody overloaded the term "functional programming" to mean
something other than {functional decomposition}? I would consider this
an error if they did. Just like the error of the term "worthless" meaning
something other than {worth less}. Something that is "worthless" is not
{worth less} it is {worth nothing}. I consider this to be an error by
whomever starting this term.

Functional programming has only ever had one meaning. Any overloading that you
see is a misinterpretation on your part. The term has never meant "functional
decomposition".

Claudio Puviani

 

[Peter Olcott]

So somebody overloaded the term "functional programming" to mean

Functional programming has only ever had one meaning. Any overloading that you
see is a misinterpretation on your part. The term has never meant "functional
decomposition".

Claudio Puviani

Then it seems to me, that what-ever it does mean could have more
aptly been attached to another term that is more descriptive of what
it actually is.

 

[Peter Olcott]

I would assume that they are reading that sentence because they intend

I haven't assumed anything about the reader's motivation. Depending on
context, then, either of our approaches might be more appropriate.

I have a business degree, and a computer science degree. In commuication
such as the one that I am describing, the method is AIDA:
Attention, Interest, Desire, Action. Any mere elaboration of the ideas
involved in OOP simply misses this point.

 

[Daniel T.]

I would assume that they are reading that sentence because they intend
to learn what object-oriented programming is. And the idea isn't to gain
the reader's interest, it's to acquaint them with the concepts.

In essence, what I'm suggesting is laying out a roadmap for the lesson -
a lesson outline, if you prefer - then following that with the lesson
itself, then showing how the lesson followed the plan to paint the whole
picture. It's a classic education strategy. What you're asking me is why
I think a student will continue the course after seeing the lesson outline.

If a student can't get past the lesson outline, they're pretty much a
lost cause to me (but maybe a real teacher would still give it a go).

Do you seriously think that a student would gain more from an abstract
theoretical discussion of the implications of concepts they are just
being introduced to? Do you think that a person incapable of getting
through a brief introduction - that contains a few terms they will
shortly be introduced to - would stand a better chance of making it
through that?

In order for the lesson to be successful, the student must be convinced
that the knowledge imparted will benefit him. If the outline doesn't
show how the knowledge will be of benefit, then the outline is useless.
The opening sentence, as well as the entire "gist" must be written in
such a way that someone who doesn't currently understand OO will, after
reading it, know *why* he should learn OO, and what he can expect to get
out of using OO.

All programmers, even BASIC newbies understand the usefulness of
reducing duplication, reducing the size of the code base, and increasing
reuse. You can talk about encapsulation and polymorphism after you get
them hooked.

 

[Daniel T.]

I haven't assumed anything about the reader's motivation. Depending on
context, then, either of our approaches might be more appropriate.

That is a mistake. The reader's motivation is to improve his life
("What's in it for me?",) if the "gist" doesn't speak to that
motivation, the reader will forget what he read before he's even done.

 

[Dave Moore]

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).

Well, I guess it depends on why you are using OOP ... if you are doing
systems-programming, as your examples seem to indicate, then modeling
"real-world objects" may indeed lead to problems. However, for
scientific programming (my application), modeling real-world objects
is often *precisely* what we are trying to do. In fact, I try to
preserve as much of the "real-world" relationships as is reasonable in
the designs of my class interfaces. Basically, the interface should
answer (at least) the questions, "What is it?" and "What can it do?",
in a way that is natural for the thing you are trying to represent.
In my experience, this facilitates program design and greatly
increases readability ... so I would say this is the the OOP paradigm
is useful for scientific programming. Once you have this, the tricky
part is "How does it do what it does", but that is an implementation
detail <grin> ... but your chosen language had better be able to do
things efficiently, or you will be waiting a long time for a result ..
this is why C++ in particular is useful.

But I digress ... more to the point, the advantages listed above for
preserving the "natural" structure and behavior of "real-world"
objects also applies for abstract concepts like files and streams.

So, to try to improve the OP's definition, how about:

OOP provides the means to create custom user-defined data types to
model "things" (be they real-world objects or abstract concepts), and
also to represent the behaviors and interrelationships that are
natural to those "things".

I am sure this still be improved, but I don't see how right now.

Dave Moore

 

[Crypticant]

<SARCASM>
I think the simplest definition for OOP is...

"Object Oriented Programming defines the ability to make small, simple
problems look like large, complex ones."

One sentence with a subject, predicate, and verb. QED.

Or, simply...

#define Object_Oriented_Programming
unsigned short int(problem) = pow(problem, 10);
</SARCASM>

-Crypticant

 

[E. Robert Tisdale]

Then it seems to me, that what-ever it does mean could have more
aptly been attached to another term that is more descriptive of what
it actually is.

In "Fundamentals of Programming Languages: Second Edition",
Ellis Horowitz calls them *applicative* programming languages.

 

[Peter Olcott]

Then it seems to me, that what-ever it does mean could have more

In "Fundamentals of Programming Languages: Second Edition",
Ellis Horowitz calls them *applicative* programming languages.

So what does that mean?

 

[Peter Olcott]

In order for the lesson to be successful, the student must be convinced

that the knowledge imparted will benefit him. If the outline doesn't
show how the knowledge will be of benefit, then the outline is useless.
The opening sentence, as well as the entire "gist" must be written in
such a way that someone who doesn't currently understand OO will, after
reading it, know *why* he should learn OO, and what he can expect to get
out of using OO.

Exactly. To put it in its simplest terms OOP makes programming easier.
The more complex the problem, the greater the benefit. I would estimate
that OOP is at least half-again easier, even on the tiniest (student homework)
projects, and at least twice as easy on the smallest real world project,
even in the immediate term. On very large and complex projects, if OOP
is done in the ball park of ideal circumstances, as opposed to the structured
paradigm under these same ideal circumstances, OOP is at least 500%
easier.

 

[Mark A. Gibbs]

Exactly. To put it in its simplest terms OOP makes programming easier.
The more complex the problem, the greater the benefit. I would estimate
that OOP is at least half-again easier, even on the tiniest (student homework)
projects, and at least twice as easy on the smallest real world project,
even in the immediate term. On very large and complex projects, if OOP
is done in the ball park of ideal circumstances, as opposed to the structured
paradigm under these same ideal circumstances, OOP is at least 500%
easier.

I think we are on different pages here. I am assuming that you
essentially have an audience of people who are there to learn the
benefits of object oriented programming, and would like to give them a
broad overview of what OO is and what it's about - ie, the "gist" of it.
It seems to me that you are assuming that you are essentially handing
out flyers on the street to random passersby, hoping to "hook" someone
onto the idea that OO is Good. I am talking about educating, you are
talking about selling.

If you're trying to *sell* OO, then you are both probably right about my
method being less than wildly successful. I've never had to "sell" a
topic before, I start on the assumption that people are there because
they've already been "sold", and now it's my job to teach. Honestly, I
can see both interpretations - wanting to "sell" and wanting to "teach"
- arising from the original post. I just assumed teach. Was I wrong?

If the goal was to "sell" OO, then perhaps I'd better bow out. I don't
do marketing. The only real suggestion I could offer is to push the fact
that OO (theoretically) involves creating self-contained bundles of
related code, that can be developed and tested by themselves, and reused
without change, without any awareness of the surrounding program
environment. I guess I would hope that the ideas of self-contained code
bundles, and write-test once/use anywhere, catches a programmer's
Interest, and Desire. I assume the Action is on their part, hm? It would
seem that all I'm missing is a "Hey, you" at the beginning to get their
Attention.

mark

 

[Peter Olcott]

If the goal was to "sell" OO, then perhaps I'd better bow out. I don't

do marketing. The only real suggestion I could offer is to push the fact

that OO (theoretically) involves creating self-contained bundles of
related code, that can be developed and tested by themselves, and reused
without change, without any awareness of the surrounding program
environment.

That's a great sell! I am not sure yet, but, that sell might be
in the ball park of ideal. I will print it out and study it.