The Gist of Object Oriented Programming

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

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]

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

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

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

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]

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

You did?


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.