By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,991 Members | 1,917 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,991 IT Pros & Developers. It's quick & easy.

The Gist of Object Oriented Programming

P: n/a
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.
Jul 22 '05 #1
Share this Question
Share on Google+
65 Replies


P: n/a
On Sun, 18 Apr 2004 17:23:16 GMT in comp.lang.c++, "Roger Smythe"
<Ro*********@hotmail.com> wrote,
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.

Jul 22 '05 #2

P: n/a
On Sun, 18 Apr 2004, Roger Smythe wrote:
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.)
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.


--
Claudio Jolowicz


Jul 22 '05 #3

P: n/a
Roger Smythe <Ro*********@hotmail.com> spoke thus:
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/

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Jul 22 '05 #4

P: n/a

"Claudio Jolowicz" <cj***@doc.ic.ac.uk> wrote in message
news:Pi*******************************@kiwi.doc.ic .ac.uk...
On Sun, 18 Apr 2004, Roger Smythe wrote:
A means for the progressive decomposition a problem space into increasingly simpler component partssuch 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.

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.
(This description skips over the OOP facilities for code reuse -
inheritance and aggregation.)
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.


--
Claudio Jolowicz

Jul 22 '05 #5

P: n/a
"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in
message news:c5**********@chessie.cirr.com...
Roger Smythe <Ro*********@hotmail.com> spoke thus:
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.


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?
--
Gary
Jul 22 '05 #6

P: n/a
"Peter Olcott" <ol****@worldnet.att.net> wrote
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
Jul 22 '05 #7

P: n/a
Claudio Puviani writes:
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.
Jul 22 '05 #8

P: n/a
> 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.
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

Jul 22 '05 #9

P: n/a
> 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.
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.

Jul 22 '05 #10

P: n/a
"Roger Smythe" <Ro*********@hotmail.com> wrote:
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.
Jul 22 '05 #11

P: n/a
> 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?
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.

Jul 22 '05 #12

P: n/a
> >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.
Ask in alt.english.usage. Plagiarize Stroustrup, e.g. sect 1.7.

Jul 22 '05 #13

P: n/a
> > > 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.


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.

Are those enough benefits for you?
--
Gary

Jul 22 '05 #14

P: n/a
Roger Smythe wrote:
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."
Jul 22 '05 #15

P: n/a
On Tue, 20 Apr 2004 01:37:02 GMT in comp.lang.c++, "Peter Olcott"
<ol****@worldnet.att.net> wrote,
>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.


Is that directed at me, or at Roger Smythe?

Jul 22 '05 #16

P: n/a
On Mon, 19 Apr 2004 22:57:27 -0400 in comp.lang.c++, Jeff Schwab
<je******@comcast.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."


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.

Jul 22 '05 #17

P: n/a
David Harmon wrote:
On Mon, 19 Apr 2004 22:57:27 -0400 in comp.lang.c++, Jeff Schwab
<je******@comcast.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."

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."
Jul 22 '05 #18

P: n/a
"Jeff Schwab" <je******@comcast.net> wrote
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
Jul 22 '05 #19

P: n/a
"Claudio Puviani" <pu*****@hotmail.com> wrote
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
Jul 22 '05 #20

P: n/a
Claudio Puviani wrote:
"Jeff Schwab" <je******@comcast.net> wrote
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.


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.
Jul 22 '05 #21

P: n/a
"Peter Olcott" <ol****@worldnet.att.net> wrote:
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?


"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".
Jul 22 '05 #22

P: n/a
"Peter Olcott" <ol****@worldnet.att.net> wrote:
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.
Jul 22 '05 #23

P: n/a
In article <41****************@news.west.earthlink.net>,
David Harmon <so****@netcom.com> wrote:
On Tue, 20 Apr 2004 01:37:02 GMT in comp.lang.c++, "Peter Olcott"
<ol****@worldnet.att.net> wrote,
>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.


Is that directed at me, or at Roger Smythe?


It's usenet, it's directed at anyone who cares to respond... :-)
Jul 22 '05 #24

P: n/a
> Is that directed at me, or at Roger Smythe?
Roger Smythe is my pseudonym

Jul 22 '05 #25

P: n/a
> > 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.


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.
Jul 22 '05 #26

P: n/a
Peter Olcott wrote:
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.

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.
Jul 22 '05 #27

P: n/a
On Tue, 20 Apr 2004 12:28:38 GMT in comp.lang.c++, "Peter Olcott"
<ol****@worldnet.att.net> wrote,
Is that directed at me, or at Roger Smythe?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.

Your pseudonym wrote: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.

Jul 22 '05 #28

P: n/a
On Tue, 20 Apr 2004 07:23:23 -0400 in comp.lang.c++, Jeff Schwab
<je******@comcast.net> wrote,
"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".)

Jul 22 '05 #29

P: n/a
David Harmon wrote:
On Tue, 20 Apr 2004 07:23:23 -0400 in comp.lang.c++, Jeff Schwab
<je******@comcast.net> wrote,
"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".)


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.
Jul 22 '05 #30

P: n/a
Jeff Schwab wrote:
David Harmon wrote:
On Tue, 20 Apr 2004 07:23:23 -0400 in comp.lang.c++, Jeff Schwab
<je******@comcast.net> wrote,
"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".)


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."
Jul 22 '05 #31

P: n/a
Roger Smythe wrote:
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/pu...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/FORS..._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.

Jul 22 '05 #32

P: n/a
"Roger Smythe" <Ro*********@hotmail.com> wrote in message news:<8Q********************@bgtnsc05-news.ops.worldnet.att.net>...
[OOP sound bite snipped]
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
Jul 22 '05 #33

P: n/a
> "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.
Jul 22 '05 #34

P: n/a
> 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.
Jul 22 '05 #35

P: n/a
> "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.
Jul 22 '05 #36

P: n/a
> 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).
Jul 22 '05 #37

P: n/a
> 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.
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

Jul 22 '05 #38

P: n/a
"Peter Olcott" <ol****@worldnet.att.net> wrote
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).


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
Jul 22 '05 #39

P: n/a
"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).

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
Jul 22 '05 #40

P: n/a
Peter Olcott 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.


That's not bad, if your target audience already understands what data
types are.
Jul 22 '05 #41

P: n/a

Claudio Puviani wrote:

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

Jul 22 '05 #42

P: n/a
Mark A. Gibbs wrote:
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?
Jul 22 '05 #43

P: n/a
"Peter Olcott" <ol****@worldnet.att.net> wrote:
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.


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...
Jul 22 '05 #44

P: n/a
> > > 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.


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.
Jul 22 '05 #45

P: n/a
> 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!
Jul 22 '05 #46

P: n/a

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?

mark

Jul 22 '05 #47

P: n/a
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.
Jul 22 '05 #48

P: n/a
"Peter Olcott" <ol****@worldnet.att.net> wrote
> 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.


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.


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
Jul 22 '05 #49

P: n/a
> > 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

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.
Jul 22 '05 #50

65 Replies

This discussion thread is closed

Replies have been disabled for this discussion.