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.

[Peter Olcott]

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

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

"Mark A. Gibbs" <x_*********@rogers.com_x> wrote:

Jeff Schwab wrote:

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?

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

Jeff Schwab <je******@comcast.net> wrote:

Mark A. Gibbs wrote:

Jeff Schwab wrote:

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.

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]

"Claudio Puviani" <pu*****@hotmail.com> wrote in message news:<Nc**********************@news4.srv.hcvlny.cv .net>...

"Peter Olcott" <ol****@worldnet.att.net> wrote

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.

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]

Peter Olcott wrote:

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

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

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.

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]

Peter Olcott wrote:

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.

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

> 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 Not duplicate, merely model the relevant abstractions, big difference.
concepts that are modeled, and sometimes, the distillation of a real world
entity into its meaningful concepts leaves little of the original image. For Except the original relationships between objects that are relevant to
the problem being solved, and some of their relevant behavior. Once
you have the relationships and behavior your system architecture is
completed.
example, in systems programming, you don't model keyboard matrices and disks,
you model streams and file systems. This is an example of good layered design, yet underneath this layer
one must still deal with the hardware. At the hardware layer it might
be a really good idea to encapsulate the hardware specific features in
its own class(s). This insulates the other layers from change when the
hardware is changed, or the system is ported. By having this hardware
specific layer, one is essentailly modelling the real world hardware.
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).

Yet even an excellent layered design must deal with the at some point.

[Daniel T.]

In article
<mX**********************@twister01.bloor.is.net.c able.rogers.com>,
"Mark A. Gibbs" <x_*********@rogers.com_x> wrote:

Peter Olcott wrote:

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.

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?

To successfuly teach you must keep the student convinced that what you
are teaching is worth learning. If you can do that, you won't need to
"teach" you will only need to help him learn (ie he will draw
information from you rather than you having to cram information into
him.)

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.

So do functions and modules in structured programming.

[Mark A. Gibbs]

Daniel T. wrote:

To successfuly teach you must keep the student convinced that what you
are teaching is worth learning. If you can do that, you won't need to
"teach" you will only need to help him learn (ie he will draw
information from you rather than you having to cram information into
him.)

No, I don't teach children, I teach adults. If they come to me and ask
me to teach them something (or worse, if they were in the class I was
asked to teach temporarily), I expect that they will keep themselves
interested. I don't need to "cram" information into anyone, all I've
ever had to do is show them the what, the why and a few how's of the
mechanisms they have to know (then I let them come up with a few more
applications - how's - on their own). I strongly discourage rote
memorization and encourage understanding each topic from first principles.

If anything, the way I keep their attention is by making a game out of
it all - I never tell them what the solution to the current problem is,
I let them come up with it (though, of course, often I have to drop
broad hints). This has always worked well for me (except when I was on
someone else's schedule - then it always felt like I had to rush).

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.

So do functions and modules in structured programming.

If you want to be that way then there is no practical way to describe
the benefits of OO that could not be used to describe the benefits of
some other paradigm... unless you throw in "unfamiliar and as-yet
meaningless technical terms".

This is why I don't do marketing, it's too nebulous for me. In the end
every programming paradigm is out to provide for better encapsulation
and compartmentalization. The only thing you can say specifically about
OO's benefits is that "some people beleive that OO acheives these goals
better than other paradigms". Nebulous, nebulous.

mark

[Daniel T.]

"Mark A. Gibbs" <x_*********@rogers.com_x> wrote:

Daniel T. wrote:

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.

So do functions and modules in structured programming.

If you want to be that way then there is no practical way to describe
the benefits of OO that could not be used to describe the benefits of
some other paradigm... unless you throw in "unfamiliar and as-yet
meaningless technical terms".

Yet I was able to do it, using terms that even a BASIC programmer (or
for that matter a non-programmer) would understand...

This is why I don't do marketing, it's too nebulous for me. In the end
every programming paradigm is out to provide for better encapsulation
and compartmentalization. The only thing you can say specifically about
OO's benefits is that "some people beleive that OO acheives these goals
better than other paradigms". Nebulous, nebulous.

Not at all, you can give concrete examples where OO makes for a better
program (or part of a program) than other paradigms. Does that mean OO
is better in all cases? Of course not, nor should you tout it as such,
but in the processes of showing the examples, the student will get an
understanding of the types of problems that OO is a good fit for.

[Mark A. Gibbs]

Daniel T. wrote:

If you want to be that way then there is no practical way to describe
the benefits of OO that could not be used to describe the benefits of
some other paradigm... unless you throw in "unfamiliar and as-yet
meaningless technical terms".

Yet I was able to do it, using terms that even a BASIC programmer (or
for that matter a non-programmer) would understand...

You did?
Not at all, you can give concrete examples where OO makes for a better
program (or part of a program) than other paradigms. Does that mean OO
is better in all cases? Of course not, nor should you tout it as such,
but in the processes of showing the examples, the student will get an
understanding of the types of problems that OO is a good fit for.

What units do you measure "better" in? When it all comes down to it,
saying that any given paradigm solves some problem "better" than others
is a personal choice. You could argue that OO solves a certain problem
more elegantly than other paradigms, but then someone would counter with
another problem that OO trips on. You could say that run-time
polymorphism is the greatest thing since sliced bread, but someone else
would balk at the run-time overhead (or god knows what else).

If you're trying to convince people that OO is "better" than some other
paradigm, you're wasting everyone's time (and liable to start an
uncalled-for flame war). But if you're trying to convince someone that
it is a powerful tool (which is NOT the same thing as saying it is a
better, or the best, tool), then you're going to have to admit to your
listeners (assuming you want to be responsibly honest) that OO is not
"better" than anything, it's merely a Good Thing.

Sometimes.

mark

[Daniel T.]

"Mark A. Gibbs" <x_*********@rogers.com_x> wrote:

Daniel T. wrote:

If you want to be that way then there is no practical way to describe
the benefits of OO that could not be used to describe the benefits of
some other paradigm... unless you throw in "unfamiliar and as-yet
meaningless technical terms".

Yet I was able to do it, using terms that even a BASIC programmer (or
for that matter a non-programmer) would understand...

You did?

Yes, I did: <po******************************@news4.west.earth link.net>

Not at all, you can give concrete examples where OO makes for a better
program (or part of a program) than other paradigms. Does that mean OO
is better in all cases? Of course not, nor should you tout it as such,
but in the processes of showing the examples, the student will get an
understanding of the types of problems that OO is a good fit for.

What units do you measure "better" in? When it all comes down to it,
saying that any given paradigm solves some problem "better" than others
is a personal choice. You could argue that OO solves a certain problem
more elegantly than other paradigms, but then someone would counter with
another problem that OO trips on. You could say that run-time
polymorphism is the greatest thing since sliced bread, but someone else
would balk at the run-time overhead (or god knows what else).

Whatever units you happen to measure "better" in, there are examples
where OO would be a better choice than some other paradigm (and of
course some in which OO wouldn't be better.) But in no case is the OO
solution any worse than a procedural solution. (Keep in mind here I'm
saying that OO is never any worse than procedural, there are other
paradigms in which this is not true, for example some problems can be
expressed better in a functional paradigm than either procedural *or* OO.

If you're trying to convince people that OO is "better" than some other
paradigm, you're wasting everyone's time (and liable to start an
uncalled-for flame war). But if you're trying to convince someone that
it is a powerful tool (which is NOT the same thing as saying it is a
better, or the best, tool), then you're going to have to admit to your
listeners (assuming you want to be responsibly honest) that OO is not
"better" than anything, it's merely a Good Thing.

I'm trying to say that OO can solve some problems "better" than
procedural (no matter how you choose to measure "better") and is never
any worse (because the set of all procedural solutions is a sub-set of
all possible OO solutions.) After all, if the procedural solution can be
expressed in C, then one can write a virtually identical program in C++.
At that point, *any* improvement (again no matter what you may think is
an improvement) made to the code that takes advantage of C++'s OO
capabilities proves that OO is better than procedural for that
particular problem.