Definition of OO
Dave Nash
Can someone give me a two-sentence definition of "Object Oriented" (from
a programming point of view) to settle a discussion we're having here.
Dave Nash
--
dn...@cerner.com Cerner Ltd, Luton, UK
Robert C. Martin
> Can someone give me a two-sentence definition of "Object Oriented" (from
> a programming point of view) to settle a discussion we're having here.
>
A way of organizing software such that function and data are bound
together in the same module; where functions are exported and data
are hidden. Where, the 'type' a module is defined only by
the functions exported by that module; and such that modules that share
the same function signatures are of the same 'type' and can be used
interchageably.
Whew.
--
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan
Ell
Robert C. Martin (rma...@oma.com) wrote:
: A way of organizing software such that function and data are bound
: are hidden. Where, the 'type' a module is defined only by
: the functions exported by that module; and such that modules that share
: the same function signatures are of the same 'type' and can be used
: interchageably.
And they wonder why I say don't read him for the fundamentals of OO.
This is at best souped up Structured programming. Good structured
programmers combined data and functions. Also good structured programmers
wrote so that they generally only changed the internals of a
module. It is such a limp, tired, raggedy, definition of OO it's
pathetic. It's not so much totally wrong, as much as it misses the
point.
I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
where they mention the roots of OO in simulation. Where they emphasize
the modelling aspect of OO. Where they mention how OO support for
polymorphism enhances the ability to model, and simulate. It's like the
pragmatists are trying to deny the existence, and significance of Simula.
The Rambo coders tremble at the whisper of *SIMULA*. :-} What is was
essentially for and all that.
Elliott
Paul Gibson
|> Dave Nash <dn...@cerner.com> wrote:
|>
|> > Can someone give me a two-sentence definition of
|> "Object Oriented" (from
|> > a programming point of view) to settle a discussion
|> we're having here.
Robert Martin replied:
|>
|> A way of organizing software such that function and data are bound
|> together in the same module; where functions are exported and data
|> are hidden. Where, the 'type' a module is defined only by
|> the functions exported by that module; and such that modules
|> that share
|> the same function signatures
~~~~~~~~~~~~~~~~~~~
|> are of the same 'type' and can be used interchageably.
|>
|> Whew.
|>
I, for what its worth, think that this just about captures my notion
of object oriented, except that I would replace "function signatures"
(as underlined by myself in the above quote) with
"exported functionality".
My reason for this is to distinguish between signatures and behaviour.
For example:
a queue of integers and a stack of integers may both
offer the same functional signatures, but one may not wish to use them
interchangeably.
( here I apologise to Robert if I misinterpreted what he meant
by "function signature")
I have just finished teaching an introductory course to
object oriented development (with C++) and the question of
trying to define the essence of OO, as concisely
as possible, arose.
I have a follow up question: David Nash asked the original question
from "a programming point of view"; I am interested to know if the answer
would be different from other points of view in the development process
(i.e. at different levels of abstraction). My initial thought is that
Robert's definition works at all levels... but I have to think
about this a bit more.
Best Regards ( and many thanks to all on comp.object for some very
interesting threads in the last few months )
Paul G.
Bruce Tobin
Robert C. Martin wrote:
>
> In article <31d8e...@www.cerner.com>, Dave Nash <dn...@cerner.com> wrote:
>
> > Can someone give me a two-sentence definition of "Object Oriented" >
>
>
> together in the same module; where functions are exported and data
> are hidden. Where, the 'type' a module is defined only by
> the functions exported by that module; and such that modules that share
> interchageably.
>
Wait a minute-- doesn't this exclude C++ (and other statically typed
OO languages)?
Mike Klein
Objects are an encapsulation of data structures and algorithms into
identifyable units of computations.
Object-Oriented programming is when objects interface to each other by
sending messages which are dynamically bound to methods.
If I had more sentences, I suppose I'd try to define messages, methods,
identity, types, classes, etc.
Always searching for good definitions,
-- mike klein
Mike Klein
> : together in the same module; where functions are exported and data
> : are hidden. Where, the 'type' a module is defined only by
> : the functions exported by that module; and such that modules that share
> : the same function signatures are of the same 'type' and can be used
> : interchageably.
>
>
>
> Elliott
Can we try and make this thread *interesting* by NOT flaming
without offering a better definition?
-- mike klein
Paul Hatchman
Dave Nash <dn...@cerner.com> writes:
>Can someone give me a two-sentence definition of "Object Oriented" (from
>a programming point of view) to settle a discussion we're having here.
This is a true quote from a Microsoft "technical" person I talked to after
a presentation.
They claimed that the product they were demonstrating wasn't object oriented,
because no menu came up when you right clicked on an "object".
So it seems pretty clear to me that if you can right click on something and
have a menu come up then it is object oriented, otherwise sorry you are
obviously using an inferior technology.
- Paul
P.S. For the humour impared, I do not consider this to be an even slightly
serious definition of OO, merely and amusing one.
--------------------------------------------------------------------------------
Paul Hatchman, | <this line intentionally left blank>
Project Leader, | pa...@sfe.com.au
Sydney Futures Exchange, Australia | Tel: +61 2 2560567
--------------------------------------------------------------------------------
Ell
Mike Klein (mkl...@alumni.caltech.edu) wrote:
You can lead a horse to water, but you can't make him drink. What do you
think I was doing in *part you SNIPPED*?
<<<I suggest the reader see one of the books by Booch, Jacobson, or
Rumbaugh where they mention the roots of OO in simulation. Where they
emphasize the modelling aspect of OO. Where they mention how OO support
for polymorphism enhances the ability to model, and simulate. It's like
the pragmatists are trying to deny the existence, and significance of
Simula.>>
Elliott
Ell
Paul Gibson (gib...@loria.fr) wrote:
: Robert Martin replied:
: |> [OO is:]
: |> A way of organizing software such that function and data are bound
: |> together in the same module; where functions are exported and data
: |> are hidden. Where, the 'type' a module is defined only by
: |> the functions exported by that module; and such that modules
: |> that share
: |> the same function signatures
: |> are of the same 'type' and can be used interchageably.
: I, for what its worth, think that this just about captures my notion
: of object oriented, except that I would replace "function signatures"
: (as underlined by myself in the above quote) with
: "exported functionality".
:
: My reason for this is to distinguish between signatures and behaviour.
While I think Marin's definition is lacking, your and his point about
signatures, or exported functionality is why myself and C++ FAQ book Cline
and Lomow emphasize subclassing principly for "substitutability" not
primarily for behavioral subtyping. See my article "The Beauty and Power
of C++" (May '95 Object magazine) for more on this.
Elliott
Steven Perryman
> Where they mention how OO support for polymorphism enhances the ability to
> model, and simulate. It's like the pragmatists are trying to deny the
> existence, and significance of Simula.
> The Rambo coders tremble at the whisper of *SIMULA*. :-} What is was
> essentially for and all that.
Well, it's nice to see someone else other than Ron Kerr saying nice things
about Simula (shouldn't the EEC be giving him a grant wrt his efforts :-) ) .
You haven't IMHO lived til you've coded in it.
Not to mention that nearly 30 years on, in the world of MI, parametric
classes and information hiding, I could write constructs in Simula that would
have many OO 'developers' reaching for clean underwear in terror ... :-)
Regards,
Steven Perryman
perr...@cpd.ntc.nokia.com
Robert C. Martin
> Robert C. Martin (rma...@oma.com) wrote:
> : A way of organizing software such that function and data are bound
> : together in the same module; where functions are exported and data
> : are hidden. Where, the 'type' a module is defined only by
> : the functions exported by that module; and such that modules that share
> : the same function signatures are of the same 'type' and can be used
> : interchageably.
>
> And they wonder why I say don't read him for the fundamentals of OO.
>
> This is at best souped up Structured programming. Good structured
> programmers combined data and functions. Also good structured programmers
> wrote so that they generally only changed the internals of a
> module. It is such a limp, tired, raggedy, definition of OO it's
> pathetic. It's not so much totally wrong, as much as it misses the
> point.
>
> I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
> where they mention the roots of OO in simulation. Where they emphasize
> the modelling aspect of OO. Where they mention how OO support for
> polymorphism enhances the ability to model, and simulate. It's like the
> pragmatists are trying to deny the existence, and significance of Simula.
>
> The Rambo coders tremble at the whisper of *SIMULA*. :-} What is was
> essentially for and all that.
Gosh, I'm reeling. What a blow! You've got one hell of an uppercut there
Elliot. Gee, I can hardly see straight. Wow, that hurt. Gosh. gee. hm.
BTW, I notice that although you expended a lot of effort slamming me (what
else is new) you did not actually answer the question.
So, Elliot, what is your definition of OO?
P.S. Simula? Brrrrrr..... I'm trembling.... The mere word frightens me.
Our intrepid Rambo Coder stalks, waste deep in water, through a dismal dark
cave. He has been trapped in there by a rogue core dump. Nothing but
some gasoling soaked rags and a stick to light his way, he explores the
twisty little passages all alike.
Suddenly he notices that the flame is not pointing straight up. Wind is
deflecting it. Where there is wind, there is a way out.
He trudges through the waste high code, deflecting patches and flags,
breaking out of loops and returning early from functions. There! Ahead,
light from above, It must be an opening.
He drops the torch, runs over to the light. Sure enough, light from the
outside world. He climbs, bracing his body against the rock hard firewalls
of the abstractions of the cave. Slowly, painfully, even fearfully, he
makes his way to the top. And there, at the top. a sign: SIMULA!
Aaahhhhhhhhhh! he cries, as he falls, trembling, back into the dark depths
of the cave.
Mike Klein
> : > Robert C. Martin (rma...@oma.com) wrote:
> : > : A way of organizing software such that function and data are bound
> : > : together in the same module; where functions are exported and data
> : > : are hidden. Where, the 'type' a module is defined only by
> : > : the functions exported by that module; and such that modules that share
> : > : the same function signatures are of the same 'type' and can be used
> : > : interchageably.
>
> : > And they wonder why I say don't read him for the fundamentals of OO.
> : [SNIP]
> : >
> : > Elliott
>
> : Can we try and make this thread *interesting* by NOT flaming
> : without offering a better definition?
>
> You can lead a horse to water, but you can't make him drink. What do you
> think I was doing in *part you SNIPPED*?
>
> Rumbaugh where they mention the roots of OO in simulation. Where they
> emphasize the modelling aspect of OO. Where they mention how OO support
> for polymorphism enhances the ability to model, and simulate. It's like
> the pragmatists are trying to deny the existence, and significance of
> Simula.>>
>
OK. No snips this time... Which two sentences from the above three
books are you attempting to lead me to?
Keep in mind that a two sentence definition isn't supposed to
enlighten a programmer who has no familiatity to OOP. It's supposed
to bring about an agreement of conciseness amongst those who are
familiar.
-- mike klein
mkl...@alumni.caltech.edu
Ell
: > I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
: > where they mention the roots of OO in simulation. Where they emphasize
: > the modelling aspect of OO. Where they mention how OO support for
: > polymorphism enhances the ability to model, and simulate. It's like the
: > pragmatists are trying to deny the existence, and significance of Simula.
: So, Elliot, what is your definition of OO?
Jacob Galley
On 11 Jul 1996 03:33:34 GMT, e...@access1.digex.net (Ell) reiterates:
> I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
> where they mention the roots of OO in simulation. Where they emphasize
> the modelling aspect of OO. Where they mention how OO support for
> polymorphism enhances the ability to model, and simulate. It's like the
> pragmatists are trying to deny the existence, and significance of Simula.
As of this morning, half of the posts in this thread are dedicated to the above
passage, which you continue to repost as though the words themselves were not
being transmitted effectively. There seem to be a few people out there who
would prefer that you expand the content of this passage, including myself.
I am a novice at oo programming, getting my feet wet in Delphi's Object Pascal.
At this point, I am starting to comprehend the potential of oo techniques. I
scan through this newsgroup almost every day in search of some illuminating
discussion that I may learn from, though most of the conversation is laden with
jargon and brief references to ideas that are still beyond me.
I do not have time to see one of the books by Booch, Jacobson, or Rumbaugh where
they mention the roots of OO in simulation. Will you please expound upon their
ideas in a brief passage here, for the benefit of us novices and the original
poster? You take the trouble to chastise Robert C. Martin's attempts to teach;
surely you can spare a few moments to explain yourself more fully.
Can you please explain what you are referring to as the modelling aspect of OO?
And how OO support for polymorphism enhances the ability to model, and simulate?
While I may sympathize with the pragmatist philosophers (Rorty and so forth), I
do not understand your reference to pragmatists in the context of oo. What do
the oo pragmatists argue?
I will assume that the existence of Simula can be taken as fact. But will you
please explain its significance?
Thank you,
Jake.
Ell
J. Galley wrote:
> Elliott wrote:
> > I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
> > where they mention the roots of OO in simulation. Where they emphasize
> > the modelling aspect of OO. Where they mention how OO support for
> > polymorphism enhances the ability to model, and simulate. It's like the
> > pragmatists are trying to deny the existence, and significance of Simula.
> As of this morning, half of the posts in this thread are dedicated to
> the above
> passage, which you continue to repost as though the words themselves
> were not
> being transmitted effectively. There seem to be a few people out there who
> would prefer that you expand the content of this passage, including myself.
>
> I am a novice at oo programming, getting my feet wet in Delphi's Object Pascal.
> At this point, I am starting to comprehend the potential of oo techniques. I
> scan through this newsgroup almost every day in search of some illuminating
> discussion that I may learn from, though most of the conversation is laden with
> jargon and brief references to ideas that are still beyond me.
>
> I do not have time to see one of the books by Booch, Jacobson, or Rumbaugh where
> they mention the roots of OO in simulation. Will you please expound upon their
> ideas in a brief passage here, for the benefit of us novices and the original
> Can you please explain what you are referring to as the modelling aspect of OO?
I mean modelling the logical analysis solution with major classes/objects
from the real world application domain. Often non-real world, and
invisible (Rumbaugh) objects are needed also, especially for medium to
large scale projects (~30kb+ lines of code)
> And how OO support for polymorphism enhances the ability to model, and simulate?
It allows one to eaily substitute one implementation, or on the other
hand, one instance of the same implementation for another. In C++ with a
single pointer to InputDevice I can activate the types card reader,
retinal scanner, fingerprint device etc. And on top of that various
specific instances of each type.
> While I may sympathize with the pragmatist philosophers (Rorty and so forth), I
> do not understand your reference to pragmatists in the context of oo. What do
> the oo pragmatists argue?
You don't see that I'm pointing out what it is in debates with Grandi,
Hopwood, and Martin? Fundamentally, they argue that OO is not based on
the real world, and they overemphasize physical implementation (coding) at
the expense of the logical - user centered requirements, analysis (a
logical solution for the application), and system architecture.
> I will assume that the existence of Simula can be taken as fact. But will you
> please explain its significance?
It was the first really OO language. It was used to simulate the shipping
operation of a Norwegian firm. The simulation had was realistic, in that
major objects in it were based on real world abstractions in the shipping
operation. Simula had polymorphism, objects, and active objects (objects
could do their own thing).
Elliott
Dave H. Griffiths
In article <4s1sme$q...@news4.digex.net> e...@access1.digex.net (Ell)
writes:
>
>I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
>where they mention the roots of OO in simulation. Where they emphasize
>the modelling aspect of OO. Where they mention how OO support for
>polymorphism enhances the ability to model, and simulate. It's like the
>pragmatists are trying to deny the existence, and significance of Simula.
It's interesting you should mention the roots of OO because I think that's
where a lot of its problems lie. OO today is being used in areas where it
shouldn't. OO was developed as you say for modelling and simulation of the
physical world. Objects had an extended life, they interacted with other
objects, the logic was naturally embedded _in_ the object.
But these days it's being used for what is basically straightforward
client-server data-entry. With the disastrous result that it vastly over
complicates the resulting software. An awful lot of what we do consists of
three basic components. There is the database. There is a screen with a
bunch of fields and a "save" button. (Stripping it to its essence somewhat
:). You type in stuff, hit save and that's where the third component comes
in: a black box who's job it is is to transfer the data back to the
database.
There's two approaches to writing this intermediate component. The
old-fashioned - and simplest one - would be to have a separate chunk of
code for every screen. All it does is takes data from the screen and
updates the appropriate database tables (or fetch and sort data from the
database or whatever). The beauty of this approach is that each chunk of
code is fairly small and pretty well decoupled from the other chunks. Of
course subroutines can still be used to share functionality amongst
chunks.
The second approach is the OO one. The black box now becomes a whole
"machine" of interacting objects. Simple operations now involve messages
bouncing around various objects. For large applications it becomes very
difficult to predict exactly what is going to happen. You tend to get far
more inefficient database useage because of side-effects of hidden
fetches. You can say "but in a well-designed system this shouldn't be a
problem", but real software is never like that.
Instead of cleanly separated chunks you have a path through a maze of
objects.
And these objects have no life of their own, unlike in the simulation
case. They are only brought into existence to solve the problem of
transferring data to and from the database. It's over-engineering. Plus
the so-called "business logic" very rarely lives completely inside
objects. You end up putting a lot of this logic into controller objects
that coordinate the activities of a number of business objects.
Not to mention the object/relational impedance mismatch. And the
brainwashing (aka training) that has to occur to stop you thinking in
terms of simple procedural solutions and start thinking webs of objects.
Whatever happened to Occam's razor when it comes to software?
I'd be interested to know how and why the square peg developed for
simulation started getting rammed into the round hole of data processing.
Dave
Andy Faibishenko
Dave H. Griffiths (dh...@ajax.wda.disney.com) wrote:
: But these days it's being used for what is basically straightforward
: client-server data-entry. With the disastrous result that it vastly over
: complicates the resulting software. An awful lot of what we do consists of
: three basic components. There is the database. There is a screen with a
: bunch of fields and a "save" button. (Stripping it to its essence somewhat
: :). You type in stuff, hit save and that's where the third component comes
: in: a black box who's job it is is to transfer the data back to the
: database.
: There's two approaches to writing this intermediate component. The
: old-fashioned - and simplest one - would be to have a separate chunk of
: code for every screen. All it does is takes data from the screen and
: updates the appropriate database tables (or fetch and sort data from the
: database or whatever). The beauty of this approach is that each chunk of
: code is fairly small and pretty well decoupled from the other chunks. Of
: course subroutines can still be used to share functionality amongst
: chunks.
Here is my problem with this approach. What gets entered into "fields"
is governed by business rules. Simple example: If the field one contains
"Indiana, Illinois, Wisconsin" then field two cannot be > .05. Another
example: If any account belonging to the customer id in field 1 contains
a negative balance, and the "Corporate" flag is not checked, disable the
"Add new account" button. This kind of logic can get really convoluted
with a screen/database approach because there is not a model of the business
rules. Furthermore, it is easy to introduce discrepancies in rules
between screens, but especially between different applications.
: Not to mention the object/relational impedance mismatch. And the
: brainwashing (aka training) that has to occur to stop you thinking in
: terms of simple procedural solutions and start thinking webs of objects.
I wish there were an easy way to connect to Rel-DBs. NeXT has Enterprise
Object Framework. Also there is Persistence from Persistence, Inc. But
I admit, at least for myself, this is usually more pain than it could be.
: Whatever happened to Occam's razor when it comes to software?
Complex problems require complex solutions?
Andy Faibishenko
Metamor Technologies, Ltd.
1 N Franklin, #1500
Chicago, IL 60606
William D. Gooch
Dave H. Griffiths wrote:
>
> It's interesting you should mention the roots of OO because I think that's
> where a lot of its problems lie. OO today is being used in areas where it
> shouldn't. OO was developed as you say for modelling and simulation of the
> physical world.
No. OO was developed for various purposes, and has many roots.
Simula (and simulation) is one, abstract data type theory is
another, frame-based AI knowledge representation is another.
It doesn't work to take the simplistic view that OO was built
for only one purpose, from only one source, or in any single
form originally.
Reading the remainder of your post, it seems apparent that you
have had experience with some rather poor designs. OO is not
the source of this problem, the designers of the software are.
Whether or not objects are well-suited to straghtforward database
applications is I suppose arguable, but I have certainly been
involved in effective OO applications of that nature.
Ther is absolutely nothing in OO that dictates you must have
a complex solution for a simple application, nor that you cannot
create solutions with good modularity, as you suggest. In fact,
my experience has been quite the opposite - that OO encapsulation
enables more control over modularity than conventional languages.
Again, you have simply been the victim of poor OO designs.
Henrik Johansson
In article <4s3cq0$v...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave H. Griffiths) writes:
> In article <4s1sme$q...@news4.digex.net> e...@access1.digex.net (Ell)
> writes:
> >
> case. They are only brought into existence to solve the problem of
> transferring data to and from the database. It's over-engineering. Plus
> the so-called "business logic" very rarely lives completely inside
> objects. You end up putting a lot of this logic into controller objects
> that coordinate the activities of a number of business objects.
>
> brainwashing (aka training) that has to occur to stop you thinking in
> terms of simple procedural solutions and start thinking webs of objects.
>
>
> simulation started getting rammed into the round hole of data processing.
>
> Dave
ability of OO to model polymorphism with the strict type checking intact
(except when using SmallTalk). This is achieved by using inheritance.
I think this is why OO has expanded out of its simulation bag.
R. Kerr
jga...@tezcat.com (Jacob Galley) wrote:
>I will assume that the existence of Simula can be taken as fact. But
>will you please explain its significance?
SIMULA is generally credited with being the first OO programming
language. It contains all the universally accepted characteristics of
OOPLs and more, e.g. active objects which are belatedly attracting
attention.
SIMULA began in the early 1960s as an extension of ALGOL 60 for the
purpose of conducting discrete event simulations. In 1967 a new
definition was produced which extended and generalised the notions of
the early version, making them applicable to the description and
construction of systems generally. SIMULA 67 introduced the notion of
classes with encapsulation, inheritance, information hiding,
polymorphism, automatic memory management and active objects, with all
that these imply. It enabled systems to be described by applying
processes of recursive decomposition and abstraction. (SIMULA classes
may themselves be defined in terms of internal class definitions.)
Literally all object-oriented products are derived to a considerable
extent from the concepts and/or mechanics of SIMULA. As someone else
has already stated, OOP has contributions from many sources. It was in
SIMULA that these coalesced. To cater for the simulation adherents of
the first SIMULA, SIMULA also contains a powerful and versatile class
of simulation aids which are defined, to all intents and purposes, in
terms of the base language. This is a good example of the application
of SIMULA's own properties.
SIMULA added new dimensions to the manner in which software systems
were popularly conceived before its arrival. Actually, it removed some
of the constraints of the conceptual straitjackets imposed by
"traditional" software architectural methods. Unfortunately, although
the mechanics of inheritance, etc., have been propagated to more
"modern" realisations of OOP, the promotion of philosophical
considerations to their users has been much less effective, and that is
why we see so many of the same old arguments and discussions recurring
in these newsgroups. Many understand the mechanisms but not the
architectural principles for applying them.
My promotion of SIMULA in this newsgroup and elsewhere has become a bit
of a joke so I will leave it to others to pick up from here if they
think fit. SIMULA is still alive and kicking and, if asked, I can
direct interested parties to sources of further information and
compilers.
Cheers....Ron
-----------------------------------------------------------------------
-
Ron Kerr, Computing Service, Newcastle University, NE1 7RU, England.
Tel. +44 191 222 8187 Fax. +44 191 222 8765 (NOTE new area
code)
-----------------------------------------------------------------------
-
Dave H. Griffiths
In article <4s3i1q$c...@nntp.interaccess.com>
an...@thymaster.interaccess.com (Andy Faibishenko) writes:
>I wish there were an easy way to connect to Rel-DBs. NeXT has Enterprise
>Object Framework. Also there is Persistence from Persistence, Inc. But
>I admit, at least for myself, this is usually more pain than it could be.
Part of what prompted my post was reading this new book called "Why Things
Bite Back - Technology & the Revenge of Unintended Consequences" by Edward
Tenner. He talks a lot about "revenge effects", how solutions to one
problem cause new unexpected problems. EOF is a good example of that. I've
been thinking about how nice and simple a Web approach to some database
applications could be. A single C cgi program per screen with embedded
sql. Real retro stuff. EOF is pretty neat but boy, does it bite back. It's
now into its third paradigm (if you include DBKit). Upgrading each time
involves a virtual rewrite. It is also a large complicated framework. You
might argue "complex solution for a complex problem", but a lot of the
problems look pretty simple. Sql is simple. Somehow with objects you just
seem to end up with a huge complex _network_ of them. I'm beginning to
think this might be an inherit tendency of the OO approach. No object is
an island. They tend, in practice, to form webs.
Dave
Andy Faibishenko
: Sql is simple.
Well, on one project I worked on we had a lot of SQL. Some was simple.
A lot had intense subqueries because we were dealing with timelines,
recursive structures, etc.Furthermore, although the SQL itself is simple,
we often had to load a bunch of stuff into memory structures and manipulate
them there due to performance considerations. I am not an expert on SQL but
the people working on this project were and they were groaning.
-Andy
Dr. Richard Botting
>Can someone give me a two-sentence definition of "Object Oriented" (from
>a programming point of view) to settle a discussion we're having here.
A quick summary of definitions so far with language rants and raves excised.
---------------------
pa...@sfe.com.au (Paul Hatchman)
So it seems pretty clear to me that if you can right click on something and
have a menu come up then it is object oriented, otherwise sorry you are
obviously using an inferior technology.
P.S. For the humour impared, I do not consider this to be an even slightly
serious definition of OO, merely and amusing one.
---------------------
Robert C. Martin (rma...@oma.com) wrote:
A way of organizing software such that function and data are bound
together in the same module; where functions are exported and data
are hidden. Where, the 'type' a module is defined only by
the functions exported by that module; and such that modules that share
the same function signatures are of the same 'type' and can be used
interchageably.
---------------------
gib...@loria.fr (Paul Gibson)
I, for what its worth, think that this [rmartin above]
just about captures my notion
of object oriented, except that I would replace "function signatures"
with "exported functionality".
---------------------
e...@access1.digex.net (Ell)
This [rmartin's defn]
is at best souped up Structured programming. Good structured
programmers combined data and functions. Also good structured programmers
wrote so that they generally only changed the internals of a
module. It is such a limp, tired, raggedy, definition of OO it's
pathetic. It's not so much totally wrong, as much as it misses the
point.
[...book pointers...]
I mean modelling the logical analysis solution with major classes/objects
from the real world application domain. Often non-real world, and
invisible (Rumbaugh) objects are needed also, especially for medium to
large scale projects (~30kb+ lines of code)
---------------------
Mike Klein <mkl...@alumni.caltech.edu>
Objects are an encapsulation of data structures and algorithms into
identifyable units of computations.
Object-Oriented programming is when objects interface to each other by
sending messages which are dynamically bound to methods.
=====================
So my 2cents worth.
Object orientation is a direction in which we all seem
to be travelling these days. Are we there yet?
For more provocation and some pointers to more serious stuff see:
http://www.csci.csusb.edu/dick/methods.html#Object
--
dick botting http://www.csci.csusb.edu/dick/signature.html
Disclaimer: CSUSB may or may not agree with this message.
Copyright(1996): Copy freely but say where it came from.
Have you heard the one about the elephant and the three methodologists?
Ell
Andy Faibishenko (an...@thymaster.interaccess.com) wrote:
: : Sql is simple.
It can get hairy.
Elliott
Ell
William D. Gooch (goo...@rwi.com) wrote:
: No. OO was developed for various purposes, and has many roots.
: Simula (and simulation) is one, abstract data type theory is
: another, frame-based AI knowledge representation is another.
: It doesn't work to take the simplistic view that OO was built
: for only one purpose, from only one source, or in any single
: form originally.
While OO brought together many aspects of sw engineering, the key thing
about OO, represented in SIMULA, was its simulation, modelling aspect.
This aspect was consciously incorporated into C++, as Stroustrup says in
many places. And it also seems to underlie the motivation for Smalltalk,
by Alan S. Kay.
Elliott
Greg Carter
Dave Nash <dn...@cerner.com> wrote:
>Can someone give me a two-sentence definition of "Object Oriented" (from
>a programming point of view) to settle a discussion we're having here.
I will assume that the discussion you are engaged in is whether two or
more people can agree on the same definition. With that in mind, I'll
throw in my two sentences worth, if only two show that there is a
bi-directional mapping between people and definitions of "Object
Oriented". ;^)
Before I do, however, I'd like to alter the question slightly and put
it as "Can someone give me a two-sentence definition of 'Object
Technology' (from a programming ... ?".
Object Technology is the latest popular evolutionary step in the
system engineer's desire to communicate system design to computers in
a manner which most conforms to the way humans perceive, understand
and communicate systems among themselves.
Hey? Do I get extra credit for giving a one sentence definition?
----------------------
Thanks,
Greg Carter
Alan Williams
dh...@ajax.wda.disney.com (Dave H. Griffiths) wrote:
>It's interesting you should mention the roots of OO because I think that's
>where a lot of its problems lie. OO today is being used in areas where it
>shouldn't. OO was developed as you say for modelling and simulation of the
>physical world.
Fair enough comment. I am going to try to add some ideas here rather
than aim to support or undermine your position.
>But these days it's being used for what is basically straightforward
>client-server data-entry. With the disastrous result that it vastly over
>complicates the resulting software. An awful lot of what we do consists of
>three basic components. There is the database. There is a screen with a
>bunch of fields and a "save" button. (Stripping it to its essence somewhat
>:). You type in stuff, hit save and that's where the third component comes
>in: a black box who's job it is is to transfer the data back to the
>database.
You can support the same model with a 3-tiered object architecture -
interface object (bunch of fields with "save" button), control object
(where you make decisions and embody understanding of the process) and
entity objects (records from the database). The interface and entity
tiers are technology dependent. The control tier takes care of the
fundamental (technology independent) logic of the system.
So what's the point? If your interface technology changes (eg: new
GUI, virtual reality, speach recognition, whatever) you _should_ have
an easier task to use it with your existing application because you
only have to change the interface objects. If your storage technology
changes (eg: company X offers you a good deal on a more advanced
product) you _should_ have an easier task because you only have to
change the entity objects. If your fundamental logic changes (eg: new
tax laws, new products) you _should_ ...
In other words, by clearly separating technology and logic you can
localise the impact of change; and what's the only thing that never
changes? Change!!
>There's two approaches to writing this intermediate component. The
>old-fashioned - and simplest one - would be to have a separate chunk of
>code for every screen. All it does is takes data from the screen and
>updates the appropriate database tables (or fetch and sort data from the
>database or whatever). The beauty of this approach is that each chunk of
>code is fairly small and pretty well decoupled from the other chunks. Of
>course subroutines can still be used to share functionality amongst
>chunks.
The problem here is that you have only considered coupling at the code
level. Coupling also occurs at the data level. If you change the
definition of a database table, you may have to change every chunk of
code that accesses that table or subroutine dedicated to that table.
>The second approach is the OO one. The black box now becomes a whole
>"machine" of interacting objects. Simple operations now involve messages
>bouncing around various objects. For large applications it becomes very
>difficult to predict exactly what is going to happen. You tend to get far
>more inefficient database useage because of side-effects of hidden
>fetches. You can say "but in a well-designed system this shouldn't be a
>problem", but real software is never like that.
>Instead of cleanly separated chunks you have a path through a maze of
>objects.
I agree if you are talking about "naive" object systems (as Ivar
Jacobson calls them). A naive object system is essentially
single-tiered; objects are not specialised for interface, control or
entity purposes.
>And these objects have no life of their own, unlike in the simulation
>case. They are only brought into existence to solve the problem of
>transferring data to and from the database.
Yes, exactly like your small decoupled black boxes.
> It's over-engineering. Plus
>the so-called "business logic" very rarely lives completely inside
>objects. You end up putting a lot of this logic into controller objects
>that coordinate the activities of a number of business objects.
Yes, that's the way to do it when you are dealing with a data munching
application.
>Not to mention the object/relational impedance mismatch.
Yes, it is a big problem, the same way that obtaining a relational
view of hierarchical data is a big problem. Then along came the
relational database and the problem went away. Now that relational
databases are taken for granted many have difficulty seeing any other
paradigm as valid. In time a similar shift may occur.
> And the
>brainwashing (aka training) that has to occur to stop you thinking in
>terms of simple procedural solutions and start thinking webs of objects.
Right. Apply simple procedural solutions to simple procedural
problems. If you have simple data with a constant structure that you
want to manipulate in unchanging ways, then use the simplest interface
and plug the data straight into a relational database. Don't waste
your time with OO for all the reasons you have mentioned.
On the other hand, if you can stand the pain of adopting OO, and if
you need to build robust systems that can handle constant change, then
you may succeed. Success will only come with due consideration of the
soft factors that are the greatest threat to the success of your OO
efforts.
>Whatever happened to Occam's razor when it comes to software?
I live in Melbourne. I want to go to Sydney. From a technological
point of view the _easiest_ way to get there is to walk, but I don't
think that's the _best_ way given other concerns such as the time it
would take.
>I'd be interested to know how and why the square peg developed for
>simulation started getting rammed into the round hole of data processing.
Some people have tried and failed and therefore abandoned the square
peg. So they shaved off the corners and gave us 3-tiered architecture.
In end it boils down to this - understand the strengths and weeknesses
of the available tools and use the most appropriate.
Kazimir Majorinc
Hello, everybody!
: In article <31d8e...@www.cerner.com>, Dave Nash <dn...@cerner.com> wrote:
: > Can someone give me a two-sentence definition of "Object Oriented" (from
: > a programming point of view) to settle a discussion we're having here.
: >
Let me try. What is asked is not mathematical type of definition, more
phylosophycal, because OO exists already and some people have experience.
Definition
~~~~~~~~~~
OO programming is programming technique which
(1) requires structural programming technique,
(2) ensures that definition of every data type contains supset or
exact list of algorithms applied on data of that type.
Structural programming is programming technique which requires that every
used algorithm is explicitelly defined and definition of every algorithm
contains supset or exact list of data types on which is applied.
This is 1-sentence definition, if structural programming is assumed.
Answer on possible critics:
~~~~~~~~~~~~~~~~~~~~~~~~~~~
C: Objects are not mentioned here.
A: Yes, but I think that only in simple cases algorithms and data
can be put together as objects in the most natural model.
Technique has object in name, but it is more general.
C: Usual requirements as polymorphism, inheritance are not
covered with this definition.
A: Yes, but I do not think they are essential for OO. I think I
could imagine structural language with these properties. For
example C++, and all classes without methods and public, maybe
some minor changes, ha?
Comment: essential of OO is that it gives more appropriate global view on
program from local point. Moreover, OO programming is possible even
without OO languages.
I'd like to hear other opinions. Please, if you following
this up, send one copy to me directly, bcs. news disapears
from my server very fast.
__________________________________________________
Author: Kazimir Majorinc, Zagreb, Croatia.
E-mail address: Kazimir....@public.srce.hr
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Matt Kennel
Ell (e...@access1.digex.net) wrote:
: You don't see that I'm pointing out what it is in debates with Grandi,
: Hopwood, and Martin? Fundamentally, they argue that OO is not based on
: the real world, and they overemphasize physical implementation (coding) at
: the expense of the logical - user centered requirements, analysis (a
: logical solution for the application), and system architecture.
I see the use of OO as an organization for *human*models*of*the*world*.
This is neither exactly 'physical implementation' (when I say physical
I mean electrons moving around) or the 'really real real world'.
It is the linkage, concrete mathematics generated by human will, and OO
a particularly perceptive and useful structure to hang it on.
In RM's corner:
Models are generated by humans for specific purposes, and
I think it's impossible to do any nontrivial classification without
attending to some general class of task.
In Ell's corner:
Still the model can have varying levels of abstraction
relevant to, and *not* relevant to, particular implementation of a particular
immediate task in a particular programming langauge. Not all human
concepts used in modelling are necessarily literally expressible in a
programming langauge, yet their absence from programming does not imply
their irrelevancy.
Whoomp, there it is.
--
Matthew B. Kennel/m...@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
*NO MASS EMAIL SPAM* It's an abuse of Federal Government computer resources
and an affront to common civility. On account of egregiously vile spamation,
my software terminates all email from "interramp.com" and "cris.com" without
human intervention.
Rajah
On Sat, 13 Jul 1996, Greg Carter wrote:
> Dave Nash <dn...@cerner.com> wrote:
>
> >Can someone give me a two-sentence definition of "Object Oriented" (from
> >a programming point of view) to settle a discussion we're having here.
>
> I will assume that the discussion you are engaged in is whether two or
> more people can agree on the same definition. With that in mind, I'll
> throw in my two sentences worth, if only two show that there is a
> bi-directional mapping between people and definitions of "Object
> Oriented". ;^)
>
> Before I do, however, I'd like to alter the question slightly and put
> it as "Can someone give me a two-sentence definition of 'Object
> Technology' (from a programming ... ?".
>
> Object Technology is the latest popular evolutionary step in the
> system engineer's desire to communicate system design to computers in
> a manner which most conforms to the way humans perceive, understand
> and communicate systems among themselves.
>
> Hey? Do I get extra credit for giving a one sentence definition?
<Applause>
Nice summation. Can anyone argue with this?
Piercarlo Grandi
>>> "jgalley" == Jacob Galley <jga...@tezcat.com> writes:
jgalley> On 11 Jul 1996 03:33:34 GMT, e...@access1.digex.net (Ell) reiterates:
Ell> I suggest the reader see one of the books by Booch, Jacobson, or
Ell> Rumbaugh where they mention the roots of OO in simulation. Where
Ell> they emphasize the modelling aspect of OO. Where they mention how
Ell> OO support for polymorphism enhances the ability to model, and
Ell> simulate. It's like the pragmatists are trying to deny the
Ell> existence, and significance of Simula.
jgalley> [ ... ] I do not have time to see one of the books by Booch,
jgalley> Jacobson, or Rumbaugh where they mention the roots of OO in
jgalley> simulation.
Actually Booch dos not say anything as silly as that: his major book so
far has a two page passage on the origins of OO and it correctly say
that the roots of OO are in cpability systems, and then mentions SIMULA,
a general purpose language only occasionally used for simulation, as a
language that expressed such ideas at the language level.
Robert C. Martin
In article <Pine.BSI.3.91.960714...@net.indra.com>, Rajah
<ro...@indra.com> wrote:
> On Sat, 13 Jul 1996, Greg Carter wrote:
>
> > Dave Nash <dn...@cerner.com> wrote:
> >
> > >Can someone give me a two-sentence definition of "Object Oriented" (from
> > >a programming point of view) to settle a discussion we're having here.
> >
> > Object Technology is the latest popular evolutionary step in the
> > system engineer's desire to communicate system design to computers in
> > a manner which most conforms to the way humans perceive, understand
> > and communicate systems among themselves.
> >
> > Hey? Do I get extra credit for giving a one sentence definition?
>
> Nice summation. Can anyone argue with this?
It echoes popular rhetoric, but is IMHO unfounded. Although I find the
object model compelling myself, I am not at all convinced that it is more
aligned with human perception, understanding, or communication; than
any other method. What evidence is there to suggest this?
Also, if perception, understanding and communication are the primary
benefits of OO; then it is not really a technology. Rather it is
a language, medium, or even an art form.
Finally, this definition says nothing at all about how OO software is
structurally different from other forms of software.
Robert C. Martin
> Robert C. Martin (rma...@oma.com) wrote:
> : In article <4rtqq0$5...@news3.digex.net>, e...@access1.digex.net (Ell) wrote:
> : > I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
> : > where they mention the roots of OO in simulation. Where they emphasize
> : > the modelling aspect of OO. Where they mention how OO support for
> : > polymorphism enhances the ability to model, and simulate. It's like the
> : > pragmatists are trying to deny the existence, and significance of Simula.
>
> : So, Elliot, what is your definition of OO?
>
> I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
> where they mention the roots of OO in simulation. Where they emphasize
> the modelling aspect of OO. Where they mention how OO support for
> polymorphism enhances the ability to model, and simulate. It's like the
> pragmatists are trying to deny the existence, and significance of Simula.
>
Reread the original post Elliott. A "two sentence definition."; not
a four sentence citing.
Robert C. Martin
In article <4s3c2e$4...@news3.digex.net>, e...@access1.digex.net (Ell) wrote:
> J. Galley wrote:
> > While I may sympathize with the pragmatist philosophers (Rorty and so
forth), I
> > do not understand your reference to pragmatists in the context of oo.
What do
> > the oo pragmatists argue?
>
> You don't see that I'm pointing out what it is in debates with Grandi,
> Hopwood, and Martin? Fundamentally, they argue that OO is not based on
> the real world,
I have argued that real world modeling is overrated and overstated.
That if too much ephasis is placed upon maintaining the "real world"
relationships between objects in a software application, that application
may be impoperly designed. I have argued that the needs of the software
structure are not the same as the needs of the 'real world' and therefore
the representation of the real-world in the software must be tempered
with concepts and structures that belong solely to the world of
software engineering.
> and they overemphasize physical implementation (coding) at
> the expense of the logical user centered requirements, analysis (a
> logical solution for the application), and system architecture.
I have emphasized implementation; but not *over* analysis or design.
I argue that analysis and design should not be allowed to proceed for very
long times without code being produced, because code is the verification
of analysis and design. I argue that a concept that appears in analysis, and
is given structure in design should be coded without delay so as to
validate and prove that the analysis and design are correct.
Thus, far from emphasizing physical implemenation at the expense of
analysis and design; I emphasize it for the purpose of validating and
reifying the analysis and design.
Robert C. Martin
In article <4s5uku$7...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave
H. Griffiths) wrote:
> Somehow with objects you just
> seem to end up with a huge complex _network_ of them.
I'd like to know the evidence you have used to come to this conclusion. Not
that I disagree with you at all. But it might be that you have been looking
at some relatively poor object oriented designs. Just because somebody
says they are doing OOD, does not mean that they are doing OOD.
Yes, object oriented designs tend to become relatively complex networks
of collaborating objects. But that should not be surprising; structured
designs tend to become relatively complex networks of collaborating functions.
Data oriented designs tend to become relatively complex networks of database
schema's, queries, triggers, and stored processes.
Why? because software is complex.
However, I will agree with you that OO tends towards more complexity than
other methods do. But with good reason. That extra complexity is
managing something that other methods ignore. i.e. the long term maintenance
of the application.
OOD is a discipline for structuring software modules in such a way that they
don't depend upon each other in detrimental ways. Through the use of
polymorphism and abstract interfaces, you can separate modules from each
other so that they are immune to changes in each other. During maintenance,
changes do not propogate through designs done in this manner. Modules
become reusable because they don't depend upon anything undesirable.
Yes, there is some extra complexity; but it serves a purpose, and it pays
back with dividends.
It is rather like calculus. calculus is complex. Think of all those
identities that have to be memorized. Yet, the complexity serves a purpose
that pays back manyfold. This would not be a very pleasant world to
live in if it werent for the fact that many people have tackled the
the complexity and gotten the payback.
Robert C. Martin
In article <4s3cq0$v...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave H.
Griffiths) wrote:
> In article <4s1sme$q...@news4.digex.net> e...@access1.digex.net (Ell)
> writes:
> >
> >I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
> >where they mention the roots of OO in simulation. Where they emphasize
> >the modelling aspect of OO. Where they mention how OO support for
> >polymorphism enhances the ability to model, and simulate. It's like the
> >pragmatists are trying to deny the existence, and significance of Simula.
>
> It's interesting you should mention the roots of OO because I think that's
> where a lot of its problems lie. OO today is being used in areas where it
> shouldn't. OO was developed as you say for modelling and simulation of the
> physical world. Objects had an extended life, they interacted with other
> objects, the logic was naturally embedded _in_ the object.
That OO has its roots in a simulation context is both debatable and
irrelevant. Certainly the book "Structured Programming" which documents
the OO aspects of Simula, does not stress "simulation" per se. Rather
it stresses the fact that the OO constructs provide interesting and elegant
new ways to structure the software and express the problem domain.
>
> But these days it's being used for what is basically straightforward
> client-server data-entry. With the disastrous result that it vastly over
> complicates the resulting software.
Granted, OO can lead to extra complexity. However, that extra complexity
has a purpose. It provides a structure in which the application can
survive for a long time. It breaks the dependencies between orthogonal
portions of the application and allows those portions to change
without affecting each other. It allows portions of the application to be
reused in other applications, etc.
Sometimes this extra complexity is not worth the benefit. However I think
these cases are very very rare. In software that has a lifetime of more
than a year, and which must suffer through continuous maintenance during
that time, the extra complexity of OO is more than paid for by the simplicity
of making changes to the system and of reusing parts of the system elsewhere.
Consider. Have you ever worked on a system in which every time you make
a change, five other parts of the application break? Have you ever noticed
that you have to change lots of unrelated portions of the software in order to
fix a bug? Have you ever fixed a simple bug and then had something in a
completely different part of the program break? These are the kinds of
software diseases that OO helps with.
OO is not just a bunch of object sending messages to each other. OO is a way
of structuring the application such that the various parts don't know about
each other, and are unaffected by change.
The most important principle in the OO paradigm is Bertrand Meyer's "Open-
Closed" principle. This principles states that software modules should be
open for extension but closed for modification. That is, you should be
able to change what a module does, without changing the module. This
sounds absurd, but it is one of the basic tents of OOD.
>
> Whatever happened to Occam's razor when it comes to software?
It is alive and well, but it does not simply concern itself with development.
It also concerns itself with maintenance, lifecycle and reuse. And when
applied in that broader context, OO often is the simplest answer.
> I'd be interested to know how and why the square peg developed for
> simulation started getting rammed into the round hole of data processing.
Whether it was designed solely for simulation is a moot point. The
ideas have always been presented as germane to the whole of software
engineering. The book "Structured Programming" published in 1972 presents
it as such.
Robert C. Martin
I will admit that the first significant Smalltalk program I studied was
a simulation. I will also admit that the first significant Smalltalk program
that I wrote was a simulation. I will even admit that according to my
readings the first significant use of SIMULA 67 was a simulation program.
However, I think that these are more coincidence than inidicative of some
underlying key concept.
I don't think that it is fair to say that OO has its roots in simulation; or
that the key thing about OO is its simulation aspect. I think this aspect
is important but I don't think it was the spark that started OO.
As evidence of this I submit the book "Structured Programming", Academic
Press, 1972. In this book, Ole-Johan Dalh, and C.A.R. Hoare describe the
interesting structural components of SIMULA-67. In effect they are talking
about OOD. Their initial example programs have nothing to do with simulations,
instead they are things like fequency histograms, calculating integrals, text
processing, permutation generation, searching binary trees, and syntax
analysers. i.e. standard software engineering problems.
Later in the book, the authors do present a problem of discrete event
simulation. It is a pretty standard system, similar to the one shown in
Wirth's book "Algorithms + Data Structures = Programs". The topics of
discussion have little to do with the appropriatness of OO for this kind
of application. Rather they talk about the need for list management, time
management, concurrency, semaphores, etc. i.e. standard software engineering
stuff.
I don't want to belittle simulation in any way. Nor do I want to insist that
OO has nothing to do with simulation. However, I think that it is unwarranted
to conclude that the key attributes of OO come from simulation. Indeed,
Dahl and Hoare say this: "The dynamic system is constructed and understood in
terms of high level concepts, which are int urn constructed and understood in
terms of lower level concepts, and so forth. This must be relfected in the
*structure* of the program which defines the dynamic system; in some way or
another the higher level concepts will correspond to program components."
So, it seems that Dahl and Hoare were more interested in the say that their
techiques affected the *structure* of software in general.
Robb Nebbe
On Sat, 13 Jul 1996, Greg Carter wrote:
>
> Object Technology is the latest popular evolutionary step in the
> system engineer's desire to communicate system design to computers in
> a manner which most conforms to the way humans perceive, understand
> and communicate systems among themselves.
>
Robert C. Martin wrote:
>
> It echoes popular rhetoric, but is IMHO unfounded. Although I find the
> object model compelling myself, I am not at all convinced that it is more
> aligned with human perception, understanding, or communication; than
> any other method. What evidence is there to suggest this?
The key is that it is closer to how we perceive the world around us.
This improves the understandability of the model which facilitates
communication.
There is quite a bit of evidence in congnitive linguistics as to the
importance of perception as opposed to an "objectivist" view point
that is independent of the observer. As for the fact that we perceive
reallity in "chunks", I'm not even sure that this is considered an open
question.
>
> Also, if perception, understanding and communication are the primary
> benefits of OO; then it is not really a technology. Rather it is
> a language, medium, or even an art form.
There is obviously a difference between superconductivity and technology
based on superconductivity. Object technology is just based on the object-
oriented paradigm. I really don't see a problem here.
>
> Finally, this definition says nothing at all about how OO software is
> structurally different from other forms of software.
Yes, but does it need to say something? The definition is meaningful to
almost anybody. If you start describing the differences in software
structure resulting from the use of OO techniques then I would say you
have just drastically cut the size of the potential audience.
If you mean that it is too superficial for a computer
scientist/engineer/programmer then I agree completely but I still like
the definition.
Robb Nebbe
Rajah
On Mon, 15 Jul 1996, Robert C. Martin wrote:
> > On Sat, 13 Jul 1996, Greg Carter wrote:
> >
> > > Object Technology is the latest popular evolutionary step in the
> > > system engineer's desire to communicate system design to computers in
> > > a manner which most conforms to the way humans perceive, understand
> > > and communicate systems among themselves.
> > >
> > > Hey? Do I get extra credit for giving a one sentence definition?
>
> It echoes popular rhetoric, but is IMHO unfounded. Although I find the
> object model compelling myself, I am not at all convinced that it is more
> aligned with human perception, understanding, or communication; than
> any other method. What evidence is there to suggest this?
There is an echo of the popular rhetoric but his use of the word
"desire" gives it a more neutral tone in my estimation.
He recognizes the desire of engineers to be more effective. He also
assumes that those engineers would want to be able to translate ideas
into practice using tools that are ".. more aligned with human perception,
understanding, or communication; than any other method."
He doesn't actually say OO *is* that toolset. He just says that the
motivation for exploring OO is rooted in the feeling that it *may* be
that toolset.
Whether OO will be viewed in the long term as a foundational tool is
still in question. Though I would think most view it as at least
promising.
His biggest assumption is that engineers want processes and tools that
are aligned with some assumed standard of " human perception,
understanding, or communication". These are quite variable from person to
person.
> Also, if perception, understanding and communication are the primary
> benefits of OO; then it is not really a technology. Rather it is
> a language, medium, or even an art form.
I would think it is all of these things in some ways depending on the
goal. TO illustrate: Is Mathematics a technology, a tool, a language, a
philosophy or an art form?
My guess is that Mathematicians will tell you "all of the above",
depending on the context.
> Finally, this definition says nothing at all about how OO software is
> structurally different from other forms of software.
Indeed. But he modified his definition to not specifically address
programming.
Where there is smoke there is usually some fire. OO seems to be smoking
up the industry so there is likely, though not certainly, some legitimate
motivation to it that is rooted in something fundamental. That fundamental
quality, if any,is currently being obscured by a good deal of smoking
hype. Some is deserved, some not.
I come from a background of electrical engineering.(BS,MS)
My areas of emphasis are advanced control theory, simulation, signal
processing and numerous other disciplines that pertain to the engineering
of robotic, guided missile and launch vehicle systems.
I am compelled by OO because it meshs well with the mathematical
foundations for control theory, (eg Linear Algebra, Non-linear systems
mathematics, transform theory, and discrete mathematical modeling of
linear systems and discrete systems.)
Specifically the mathematics that are used to describe and design control
laws for multi-input, multi-ouput systems. (De-coupling strategies,
Observability/Controllability issues, etc.)
These are my reasons for being excited about object "technolgy". Some of
it is gut feeling, some is based in mathematical foundations that are
well-established in my field of origin.
Whether my excitement is well-founded is not fully evident to me yet. Its
looks likely though.
Roger T.
Rajah
On Mon, 15 Jul 1996, Robert C. Martin wrote:
> In article <4s3c2e$4...@news3.digex.net>, e...@access1.digex.net (Ell) wrote:
>
> > J. Galley wrote:
> > > While I may sympathize with the pragmatist philosophers (Rorty and so
> forth), I
> > > do not understand your reference to pragmatists in the context of oo.
> What do
> > > the oo pragmatists argue?
> >
> > You don't see that I'm pointing out what it is in debates with Grandi,
> > Hopwood, and Martin? Fundamentally, they argue that OO is not based on
> > the real world,
>
> I have argued that real world modeling is overrated and overstated.
> That if too much ephasis is placed upon maintaining the "real world"
> relationships between objects in a software application, that application
> may be impoperly designed. I have argued that the needs of the software
> structure are not the same as the needs of the 'real world' and therefore
> the representation of the real-world in the software must be tempered
> with concepts and structures that belong solely to the world of
> software engineering.
I agree with you but.... Physicall world modeling in traditonal
engineering fields is effective and useful because the real world is
well-defined by the physical laws of the real world.(i.e., Everyone uses
the same physical laws, Newton, Maxwell, Einstein, etc.)
The software world needs similar stable foundations or attempts at
modeling "software world" systems for purposes of prediction or targeted
design will always be ad hoc, one-off solutions. Design patterns is a
good first step.
Roger T.
Markus Olbrich
> It is alive and well, but it does not simply concern itself with development.
> It also concerns itself with maintenance, lifecycle and reuse. And when
> applied in that broader context, OO often is the simplest answer.
I agree to this answer from Robert Martin and would like to extend it:
0: For a "hello world" program you will spend multiple times the amount of
time than for the same functional or dirty program that only tries to
solve this problem as quickly as possible.
But imagine in the near future (perhaps CORBA leads to it) you will be
able to specify a flag or attribute on an object, so that it will become
persistent and another flag allows it to be spread over networks and hold in
the memory of different machines and you havent to care about this at all.
Then if you looked a bit to the future and invested this amount of time,
you will extend your code by some lines and avoid using database systems or complex
distributed environment systems or complety redesign of your applications.
(This is only an example)
1: Some programmers think object-orientation = C++. C++ has a lot of
features and is a complex language => therefore object orientation is
complex and hard to understand. I don't think so. It is the missing of
a unique definition of the fundamental principles of OO. I took about one year
to read the books from Booch, Rumbaugh, Coplien and a lot articles in journals
to come to the point recognizing that none of them was able to define it
(defined like a user of OO, an engineer, would like it to be defined; and i think
engineers are one of the groups this method is mainly addressed to).
But nonetheless they sold 3 books and a lot of journals.
2: This is one reason
object-orientation should not be defined from the point of view of the
programming language. Object-oriented class- and object-models should
be language independent and in the future perhaps programs shall be code-
generated from models in a wide range. This depends on the clear and
unique definition of object-oriented fundamentals.
3: Object-oriented models can be designed by different methods and points
of view. This is one of the essential aspects in the different methods
by Booch, Rumgbaugh, Jacobsen et al. If functional aspects drive the
developement in the very few stages of system design, start with
iterations of functional models;if dynamic aspects are dominant perhaps
you might start with the dynamic (use-cases / state diagrams) models.
But all of them correspond to some object- and class models in an
orthogonal view of the system based upon the fundamental principles of OO.
4: Most of the object-oriented approaches to software development such as reuseable,
maintainable, reliable and extendable class hierachies and language independant
time stable models for complex systems
can only be realized after one or more cycles of a software release. But many people
are shocked about the OO-method and f.e the C++ languages complexity; so they fall back to
the well known methods and will never realize this approach.
5: Make the methods simple. Explain and define GENERALISATION, ASSOCIATION and AGGREGATION
and some pattern precisions of that groups of relationships at a maximum of perhaps 20
pages. Each pattern should be followed by simple but well choosen examples.
Formulate unique idioms and patterns to implement each of the OO features;
that will allow simple re-engineering methods.
For the experts, that would like to look inside the internal foundation of theory,
put them in a separate chapter, but write them down.
Then i will look confidential ahead to the future, that OO-experts and programmers, that know to
implement, extend and maintain this software, will be able "to earn their daily bread" (we like to say in german, direct translation) in this area; and i will be able to rely on the software that
controls the traffic lights of the city of tomorrow when i try to cross the road and this software
calculating with finite elements or something similar the buildings we live in.
--
------------------------------------------------------------------------------
xx xx Institut für Bauinformatik
xx x Am kleinen Felde 30
xx D-30167 Hannover
xxx Markus Olbrich (Dipl.-Ing.)
x xx Tel.:49-511-762-5938
xx xx E-Mail: olb...@bauinf.uni-hannover.de Fax :49-511-762-4756
------------------------------------------------------------------------------
Patrick Logan
Mike Klein wrote:
>
> > [OO vs. Procedural beer]
>
> Aren't we glad that when we want to open beer, there are only
> 3 standard interfaces (pull tab, screw-off, and non-screw-off).
>
> And, only 2 of them are virtually indistinguishable. What's more,
> if you accidentally mistake non-screw-off for screw-off, you
> merely cut your hand... The bottle doesn't break and people don't die.
>
> If only the software world were so well designed...
If only there were so few degrees of freedom. The only thing one
could do with software is to open containers.
The whole point of software is that it is a brand-new
mechanism for relatively quickly building special-purpose machines.
It should come as no surprise that there are an infinite variety
of choices in software.
Patience is a virtue...
--
mailto:Patrick...@ccm.hf.intel.com
"Analysis means taking things apart for examination, while
design is to work out the structure or form of something."
-Seamless Object-Oriented Software Architecture, Walden & Nerson
Patrick Logan
Dave H. Griffiths wrote:
> Logic is being squeezed into objects where it shouldn't be. A typical
> business use case is about a process. That process will involve
> reading/modifying various bits of data. When you come to squeeze it into
> objects, you often find that a coherent piece of process is now split and
> divided amongst half a dozen objects. A completely separate process may
> use some of those objects, may use some more, thus creating linkages all
> over the place. A single obect may contain logic for a number of
> processes.
Oh. I see. It seems you are talking about *poor* object-oriented
designs!
OO is a way of simplifying. If you are creating poor, complex
object-oriented designs, then by all means, stop it!
8*)
Marc Grajower
Robert C. Martin wrote:
> Consider. Have you ever worked on a system in which every time you make a change, five other parts of the application break? Have you ever noticed
that you have to change lots of unrelated portions of the software in order
to
fix a bug? Have you ever fixed a simple bug and then had something in a
completely different part of the program break? These are the kinds of
software diseases that OO helps with.
Robert,
Would you say then, that (1) if one considers that spaghetti code is not
posing a big problem and (2) if the projects one is specialised in, are in
nature not complex from a programming design point of view, that in such a
case OO is not the right way?
Marc
Markus Olbrich
There are several subjects in this group concerning the central point of
(sorry therefore posting this article multiple times (3))
WHAT IS OBJECT ORIENTATION
I will not at all try to answer this here, but i would propose to all experts
discussing here to first of all concentrate on clearing this thesis before talking
about a lot of other more complicated exmaples and imaginable things.
I realized more than only one question here that initiated a subject that seamed
very easy could sometimes be from a novice, but is does not take long after 2 or 3 followups the discussion is spread and becomes "religious", so that the initiator of this question is not willing to follow this any more.
I started the same way and i understand questions that ask:"Does object-orientation imply that a program must use inheritance to be object-oriented." I formulated exactly this for my students last year i read the first german book about object-oriented modelling form G.Booch we all know it.
In the english version he said (Object-Oriented Anlysis and Design with Applications, G. Booch, 2nd ed. 1994, page 38):
>
> Object oriented programming is a method of implementation in which programs are organized as
> cooperative collections of objects, each og which represents an instance of some class, and
> whose classes are all members of a hierarchy of classes united via inheritance
> relationships.
>
> These are three important parts to this definition :
>
> (1) object oriented programming uses objects,
> not algorithms, as its fundamental logical building blocks (the part of hierarchy we
> introduced in chapter 1);
>
> (2) each object is an instance of some class;
>
> (3) and classes are related via inheritance relationships (the "is-a" hierarchiy we spoke of
> in chapter 1).
>
> A program may appear to be object-oriented, but if any of this elements is missing, it is not
> an object-oriented program.
> Specifically programming without inheritance is distinctly not object-oriented,
> we call it programming with abstract data types.
>
This definition of object-orientation is one of the wide spread definitions all over the world and read by most of novice object-oriented programmers. There are a lot of words in this sentences and we
could start a religious discussion about almost every word he said. But that would be strongly against
my intention i wrote this article for.
I think we all must imagine the date these definitions are publicly presented. Someone must begin
to start to spread his ideas in a world of scientists and the other must respond and communicate
in order to exchange ideas and push science towards better methologies. This does not at all mean, in my opinion, that nearly a war about personal opinions breaks out. It would be much more helpful
for the community of computer scientists to bring together all the facts and a founded thesis in order
to be able to formulate a definition of object orientation that helps us all to build powerful and reliable software systems for the future.
If we will not succeed this definition in the next future, then i fear object-orientation might be canceled and thrown away because no normal programmer is able to understand it. One example for this behaviour i believe to see in the JAVA discussion versus C++ goiong on here and not only here, also in our institute. People, mathematics and engineers, who could not yet be persuaded about the advantages and prinvciples of OO are trying JAVA and think this could be a much simpler to use advance to better programming. But i dont want to grep this discussion here, here i had another intention.
I think time runs and time has come that the known experts (Booch/Rumbaugh/Coplien/Jacobsen) take part in this discussions here and defend or discuss and perhaps modify their theses about object-orientation and its fundamental principles.
Everyone who reads a book of this kind, mentioned above, shows, that he is willing do spend time to learn the principles of object-orientation and not only programming in C++ (for exmaple C++). So please lets put together all we learned about this in the last years and formulate precise definitions for object-oriented
modeling and design and programming.
I think there are a lot of aspects in the definition above that are near to the right one, but i don't agree
to the havy meaning of inheritance he defined. Looking at some implementations and OO-models in civil engineering and especially small programs, inheritance is of little interest. Often it is only the above definition that leads
us to search for something we can inherit, even if there is nothing in the program that should be inherited.
But if we don't inherit, than we can't call our program object-oriented.
I think objects and relationships are the fundamental principles of OO, and relationships as far as i am now can be of kind AGGREGATION, ASSOCIATION or GENERALISATION. The principle of building objects as a union of data and its modifying methods, and defining states of objects as a snap-shot of their attribute values is quite clear. The relationships of all those three kinds are not yet clearly defined;this is the point we should first of all concentrate on before trying to solve very complex real problems.
Once more, i dont like such discussions that get a light religious character and this article might be seen
so by someone, but all i want is to get facts and clear information about the principles of object-orientation, because i like the method (not only C++) and i think it will help us to construct software like an architect for complex systems. We will try to solve our whole universe with this software
and i want to be able to rely in such systems and understand their fundamentals.
I hope my article is one to force this discussion in the right direction. Please try thinking also
about the process of novices and students learning this method and reading one of the popular books after
the others.
In the discussion about books i would propose not to forget the one of J.O. Coplien; i found this one of the best for the principles.
In addition i think one must differentiate if we are talking about notation-methods, principles of OO or about implementation details and possibilities in different languages.
Notation-methods represent a big part in the books of Booch and Rumbaugh and different points of view lead to
the object and class models using different methods perhaps also use-cases, Booch-method and OMT.
But don't they all are named object-oriented design ? If object-orientation is a method with defined
principles, then all these methods must lead to nearly the same models, not depending upon which method is used to find them. It is the same with the OO languages; all of them should be able to implement each of the
object-oriented principles. But how shall we judge about an OO-language if we don't know exactly what these
principles are? This leads for example to the question "is multiple-inheritance a fundamental principle of OO and must it be supported by a language directly to be called OO-language?".
I am i little disappointed about that no one of the most popular group (just mentioned above) takes part in this discussions here to clear up some situations and defend and discuss their theses. I hope they are not only writing big books with many pages in order become rich and popular or developing CASE tools because this is one of the fields money can be earned with software today (most simple things are PD today). I am sure they are scientists but have no time to talk about this here.
Mike Klein
> [OO vs. Procedural beer]
Aren't we glad that when we want to open beer, there are only
3 standard interfaces (pull tab, screw-off, and non-screw-off).
And, only 2 of them are virtually indistinguishable. What's more,
if you accidentally mistake non-screw-off for screw-off, you
merely cut your hand... The bottle doesn't break and people don't die.
If only the software world were so well designed...
-- mike klein
mkl...@alumni.caltech.edu
Dave H. Griffiths
In article <rmartin-1507...@vh1-006.wwa.com> rma...@oma.com
(Robert C. Martin) writes:
> That OO has its roots in a simulation context is both debatable and
> irrelevant.
The relevance is that I'm arguing that OO is good for simulation of the
_physical_ world and bad for modelling of the _mental_ world which makes
up a lot of the business logic we have to capture.
I think people saw its success in simulation, they could intuitively grasp
its use in that context and they then went on to apply it to other things.
> Certainly the book "Structured Programming" which documents
> the OO aspects of Simula, does not stress "simulation" per se. Rather
> it stresses the fact that the OO constructs provide interesting and
elegant
> new ways to structure the software and express the problem domain.
I agree that they do provide _a_ way. The problem we have is that they are
now used as _the_ way.
Logic is being squeezed into objects where it shouldn't be. A typical
business use case is about a process. That process will involve
reading/modifying various bits of data. When you come to squeeze it into
objects, you often find that a coherent piece of process is now split and
divided amongst half a dozen objects. A completely separate process may
use some of those objects, may use some more, thus creating linkages all
over the place. A single obect may contain logic for a number of
processes.
We are also creating a whole realm of meta-objects. By meta-objects I mean
objects that have no direct parallel in the real world. We have to create
meta-objects because the processing has to go somewhere, and we've become
conditioned to thinking that "somewhere" is inside an object. Look at any
OO program and the vast majority of objects are meta-objects.
I've become so used to thinking in terms of objects that I've got into the
habit of thinking meta-objects are "natural". But most of them are not.
They're simply a by-product of the fact that the logic has to go somewhere
in an OO language.
> [...] It provides a structure in which the application can
> survive for a long time. It breaks the dependencies between orthogonal
> portions of the application and allows those portions to change
> without affecting each other.
Some of the best examples of that I've seen have been in non-OO fields.
The Unix kernel for instance with the device driver and virtual file
system polymorphism. Layered comms protocols is another example. OO
doesn't break the dependencies between different portions, the software
designer does.
> Sometimes this extra complexity is not worth the benefit. However I
think
> these cases are very very rare. In software that has a lifetime of more
> than a year, and which must suffer through continuous maintenance during
> that time, the extra complexity of OO is more than paid for by the
simplicity
> of making changes to the system and of reusing parts of the system
elsewhere.
It depends on how minor the changes are. For small changes I would agree,
but in my experience, software is always undergoing big changes. With an
OO system these changes are not confined to the "inside" of an object,
they are usually about the way a bunch of objects interact with each
other. And because of the higher degree of coupling that OO encourages
(even though maybe it shouldn't), your changes have ripples elsewhere in
the "crystal" of objects.
Dave
Robert C. Martin
In article <4sha1j$8...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave
H. Griffiths) wrote:
> Logic is being squeezed into objects where it shouldn't be. A typical
> business use case is about a process. That process will involve
> reading/modifying various bits of data. When you come to squeeze it into
> objects, you often find that a coherent piece of process is now split and
> divided amongst half a dozen objects. A completely separate process may
> use some of those objects, may use some more, thus creating linkages all
> over the place. A single obect may contain logic for a number of
> processes.
That this happens is certainly true. That it is part of proper OOD is
certainly false. In OOD we attempt to keep processes that don't belong
in an object, out of the object. That is why patterns like Visitor, and
techniques such as Jacobson's "Controller" objects are so important. They
address this very issue.
Yes, there has been a naive trend in some OO circles to "Squeeze" a bunch
of functionality into objects. But should not be taken as proper OO design.
In the kinds of scenarios you are talking about, I would expect that the
designer would decide which business rules really belonged in an object, and
which were part of the application rather than intrinsic to the object. Those
that were application specific would then be placed in objects of their own.
This prevents the "splitting" you were talking about, and does not create
the linkages "all over the place". Indeed, one of the most important goals
of OOD is to prevent linkages from being created all over the place.
> We are also creating a whole realm of meta-objects. By meta-objects I mean
> objects that have no direct parallel in the real world. We have to create
> meta-objects because the processing has to go somewhere, and we've become
> conditioned to thinking that "somewhere" is inside an object. Look at any
> OO program and the vast majority of objects are meta-objects.
I know those that would disagree with this statement. I, on the other hand,
think that *all* objects are meta-objects. i.e. no object is a perfect
representative of the real world. It does not scare me that many of the
classes in a well designed OO system do not have real-world correspondents.
This is one of Jacobson's most strongly made points. Stable systems are
built from more than just real world entities.
>
> I've become so used to thinking in terms of objects that I've got into the
> habit of thinking meta-objects are "natural". But most of them are not.
> They're simply a by-product of the fact that the logic has to go somewhere
> in an OO language.
I hope they are a by-product of something else. I hope they arise because
they represent interfaces that stop the propogation of change from one
module to another. If they are truly, as you say, only repositories for
logic then your are using the wrong design principles.
> OO
> doesn't break the dependencies between different portions, the software
> designer does.
Granted, absolutely. However, OO provides some very nice tools for
managing dependencies. The designer that tries to manage dependencies
without using OO techniques has a long row to hoe. He winds up using
pointers to functions and lots of indirection. OO makes this quite a bit
simpler.
>
>...in my experience, software is always undergoing big changes. With an
> OO system these changes are not confined to the "inside" of an object,
> they are usually about the way a bunch of objects interact with each
> other. And because of the higher degree of coupling that OO encourages
> (even though maybe it shouldn't), your changes have ripples elsewhere in
> the "crystal" of objects.
If you have a "crystal of objects" through which changes ripple, then you
absolutely do not have an object oriented design. At best you have a design
with a bunch of objects. There is a big difference. The principles of OOD
are specifically intended to prevent that crystal from forming. And, in
my experience, they do a tolerable job.
The very first such principle was coined nearly a decade ago by Bertrand
Meyer. It is named the Open/Closed principle. This principle states that
a software module should be open for extension but closed for modification.
This means that you should engineer each module in your application such
that its behavior can be changed without modifying the module. One of the
simplest ways of doing this is by using abstract polymorphic interfaces.
The Open/Closed principle could be considered the "high principle" of OOD.
It states the goal. Indeed, I think it states the criterion by which all
OO designs can be measured. If you have an application designed with objects,
and yet you cannot make major changes by adding new modules rather than by
changing old working modules, then your design is not object oriented.
For more on the various principles of object oriented design, download my
"Principles of OOD" paper from the freeware section of my website.
Dave H. Griffiths
In article <4sgie4$r...@newsserver.rrzn.uni-hannover.de>
olb...@bauinf30erib.uni-hannover.de (Markus Olbrich) writes:
> But nonetheless they sold 3 books and a lot of journals.
Bingo.
Dave
Dave H. Griffiths
In article <31EC38...@ccm.hf.intel.com> Patrick Logan
<patrick...@ccm.hf.intel.com> writes:
> Oh. I see. It seems you are talking about *poor* object-oriented
> designs!
>
> OO is a way of simplifying. If you are creating poor, complex
> object-oriented designs, then by all means, stop it!
Suppose there's a way of making bridges out of marshmallow, but it's quite
tricky - you can do it if you're good at it. Most of the people who build
these bridges aren't very good at it and they keep collapsing, especially
when it rains. So someone comes along and says "hmmm, perhaps building
bridges out of marshmallow is not such a good idea". Would you tell them
to just stop building the poor ones?
:)
Dave
Arthur Riel
Marc Grajower wrote:
>
> Robert C. Martin wrote:
>
>
> > Consider. Have you ever worked on a system in which every time you make a change, five other parts of the application break? Have you ever noticed
> that you have to change lots of unrelated portions of the software in order
> to
> fix a bug? Have you ever fixed a simple bug and then had something in a
> completely different part of the program break? These are the kinds of
> software diseases that OO helps with.
>
>
> Would you say then, that (1) if one considers that spaghetti code is not
> posing a big problem and (2) if the projects one is specialised in, are in
> nature not complex from a programming design point of view, that in such a
> case OO is not the right way?
>
> Marc
The object-oriented paradigm uses abstraction, encapsulation, and the creation of
abstract polymorphic interfaces to control essential complexity. These are all
well documented development techniques. The real question is not, "Is OO the
right way for a project?". These techniques can always be applied. The real
question is, "Is the level of complexity of my application sufficient to justify
the extra work needed to produce an OOD?". It is true that there is some break
even point to the work of producing the OOD versus the saved efforts (for one,
reduced maintenance costs). We wouldn't implement the Hello World program by
first producing an OOD. I'm not sure where this break even point is, but in
my experience, if you have more than one developer involved you have reached it.
Notice it is not that OO is the wrong way, its just not worth the effort for
trivial problems. If you aren't worried about spaghetti code then by definition
you must be building something trivial.
Arthur Riel
Dave Harris
Dave Nash <dn...@cerner.com> wrote:
> Can someone give me a two-sentence definition of "Object Oriented" (from
> a programming point of view) to settle a discussion we're having here.
Software based around, in order of importance:
(a) Abstract Data Types;
(b) dynamic polymorphism;
(c) some form of delegation or inheritance;
(d) automated memory management or garbage collection.
This definition is actually so wrong it would be difficult to defend in a
newsgroup like comp.object. (I hope Piercarlo Grandi is not reading this.)
Still, it is a useful real-world guide to the language features you want
if you are to do what most people call "object oriented programming".
Dave Harris, Nashua, NH USA. | "Weave a circle round him thrice,
bran...@cix.compulink.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
- I speak only for myself - | And drunk the milk of Paradise."
Bradley K. Sherman
In article <31ec9...@info4.uni-rostock.de>,
Juergen Schlegelmilch <schl...@Informatik.Uni-Rostock.de> wrote:
>It's always the same:
>
> The favorite game of the opponents of the [object-oriented]
> approach is to ask a crowd of object-oriented zealots to
> define object-orientation: The result is in general a civil
> war among the crowd.
>
>This was F. Bancilhon, 1988 [Proc. ACM SIGACT/SIGMOD 1988, pp.152-162]
>
>Obviously, there hasn't been any improvement over the last eight
>years.
Why is this so? I have trained many young people to use
structured techniques and they do not end up asking me
questions about reality or the meaning of life and the
psycholinguistics is limited to an occasional foray into
Chomsky grammars.
There is an article by B. Meyer in the current _IEEE Computer_
warning OO designers *not* to get hung up on making objects
in the system analogous to objects in the environment!
And pity the poor Junior programmer of 2001 who has to
maintain these turgid experiments!
The central dogma of computers is: Increment
the program counter. Until this changes, computer
programming is inherently procedural.
--bks
Rajah
On Tue, 16 Jul 1996, Robert C. Martin wrote:
[beer analogy snipped]
> What evidence is there to support that the second form is
> more in line with human perception than the first? On the
> surface of it, I'd say the first is much more in line with
> human perception. But then I represent only a single data point,
> not conclusive evidence.
As you have illustrated, OO terminology does not add clarity to any specific
process dexscription. However when the human being attempts to generalize
processes the terminology suddenly becomes very powerful and descriptive.
If you wanted to model how humans seek, attain and consume foods/beverages
then generalized OO models would offer added flexibilty and efficiency
for the modeler that did not want to merely document every possible
variation of food/beverage aquisition and consumption.
It is the human tendency for seeking abstraction that OO is in line with.
It does not offer any major utility in how any particular task is
described that is better that the pure procedural desciption.
> > There is quite a bit of evidence in congnitive linguistics as to the
> > importance of perception as opposed to an "objectivist" view point
> > that is independent of the observer.
>
> I'll grant you this. I believe it. But what has it to do with
> OO being in line with human perception.
It is in line with how humans perceive and perform abstraction.
> > As for the fact that we perceive
> > reallity in "chunks", I'm not even sure that this is considered an open
> > question.
>
> But is the question germane? Objects are "chunks" with well defined
> interfaces. Do we percieve reality in that kind of chunk? Or is our
> perception much more complex than that. i.e. when looking at a scenario
> from one viewpoint we "chunk" it a certain way. When looking at it from
> another viewpoint we "chunk" it a different way. Do we really see reality
> in static chunks? Or are the chunks constantly merging, splitting, dissovling
> and reforming like soap bubbles in the sink?
Yes to both. But the constant is the use of the idea of chunk. The chunks
coalesce, merge and then they often split, dissolve and coalesce into
something new.
> Where is the evidence to support that humans percieve the world as a set of
> static chunks with firm boundaries that present immutable interfaces?
Cognitive research points in this direction. Though not with absolute
finality.
> > There is obviously a difference between superconductivity and technology
> > based on superconductivity. Object technology is just based on the object-
> > oriented paradigm. I really don't see a problem here.
>
> Superconductivity is supported with lots of empirical evidence. We know
> how to use superconductors because we have observed them work. Our
> technology is based upon those observations.
>
> However, if OO is really just a better way of saying something, then there
> is no empirical evidence to support a new technology; rather there is just
> a better way of expressing an old one.
So its a cognitive technology. Technology doesn't *have* to mean
something new materially. If it does I think the meaning of the word is
going to evolve.
Roger T.
Rajah
On Wed, 17 Jul 1996, Robert C. Martin wrote:
> In article <Pine.BSI.3.91.96071...@net.indra.com>, Rajah
> <ro...@indra.com> wrote:
>
> > I would think it is all of these things in some ways depending on the
> > goal. TO illustrate: Is Mathematics a technology, a tool, a language, a
> > philosophy or an art form?
> >
> > My guess is that Mathematicians will tell you "all of the above",
> > depending on the context.
>
> Doubless this is true. However, it is quite debatable whether mathematics
> is "in line with human perception".
A good deal of mathematics is in fact quite in line with human
perceptions. The base 10 numbering system walks hand in hand (pun
intended) with not only human perception but human physiology.
The parts thaare not in line with human perception are, however, right
in line with something even more fundamental and unchangeable, the
physical universe.
> Most people find mathematics quite
> impenatrable until they work hard to learn it. And the results of
> some mathematics (i.e. Quantum Mechanics) are even less intuitive than
> that the mathematics itself.
This is true. And if humanity had the power to change the way things
happen in this universe we might do it because a universe more in line
with human perception would be a much more fertile ground for getting
things done.
Which is why :
if:
( the creation of reliable, flexible,complex systems require extensive
use of abstraction.)
and:
( it can be conclusively shown that OO is closer to how
humans naturally perform abstraction than the traditional approaches)
and:
( OO techniques can provide the ability to perform all the tasks
currently supported by traditional techniques)
then:
( it should be adopted as a standard.)
because:
( it will result in increased productivity and higher quality.)
Of course tools must be used by those who know how to use them.
It's no free lunch.
Roger T.
Robb Nebbe
Robert C. Martin wrote:
>
> ...What evidence do we have that this is the case?
> When I drink a beer, do I really percieve this as messages passing between
> myself, the mug, the beer, my throat, etc?
The message passing metaphore is more an artifact of the way Smalltalk
is implemented that something essential to the OO paradigm in my opinion.
Standard procedures and functions work just fine; the OO part is deciding
to which type they belong.
>
> Where is the evidence to support that humans percieve the world as a set of
> static chunks with firm boundaries that present immutable interfaces?
There is an enormous amount of linguistic evidence that our perception is
based on things with firm boundaries. As for immutable interfaces, I would think
that multiple immutable interfaces would be a reasonable approximation in the
majority of cases. After all, the point isn't that the OO approach corresponds
exactly to how our perceptions works but rather that it is closer and thus
better.
Some linguistic evidence off the top of my head:
There is a special category for nouns that designate things without firm
boundaries that is treated as a special case such as "water". If we use
the normal plural "waters" then we are talking about something with a well
defined boundry such as territorial waters.
We tend to have words for individuals, sets of individuals and specific
kinds of individuals. Languages I'm familiar with are much less rich when
talking about things without well defined boundries. As an example consider
that most languages have names for any common animal and separate names for
the male, the female and the baby as well as a name for the group of animals.
I believe most Indo-European languages are the same. Anyone who speaks
something from some other language family care to comment?
Robb Nebbe
Robert C. Martin
rmartin said:
> > Also, if perception, understanding and communication are the primary
> > benefits of OO; then it is not really a technology. Rather it is
> > a language, medium, or even an art form.
>
> I would think it is all of these things in some ways depending on the
> goal. TO illustrate: Is Mathematics a technology, a tool, a language, a
> philosophy or an art form?
>
> My guess is that Mathematicians will tell you "all of the above",
> depending on the context.
Doubless this is true. However, it is quite debatable whether mathematics
is "in line with human perception". Most people find mathematics quite
impenatrable until they work hard to learn it. And the results of
some mathematics (i.e. Quantum Mechanics) are even less intuitive than
that the mathematics itself.
--
Juergen Schlegelmilch
It's always the same:
The favorite game of the opponents of the [object-oriented]
approach is to ask a crowd of object-oriented zealots to
define object-orientation: The result is in general a civil
war among the crowd.
This was F. Bancilhon, 1988 [Proc. ACM SIGACT/SIGMOD 1988, pp.152-162]
bviously, there hasn't been any improvement over the last eight
years.
Juergen Schlegelmilch
--
+-----------------------------------------------------------------------------+
Dipl.-Inf. Juergen Schlegelmilch University of Rostock
email: schl...@Informatik.Uni-Rostock.de Computer Science Department
http://www.informatik.uni-rostock.de/~schlegel Database Research Group
Tel: ++49 381 498 3402 18051 Rostock
Fax: ++49 381 498 3404 Germany
+-----------------------------------------------------------------------------+
Piercarlo Grandi
>>> "nebbe" == Robb Nebbe <ne...@iam.unibe.ch> writes:
[ ... ]
rmartin> Where is the evidence to support that humans percieve the world
rmartin> as a set of static chunks with firm boundaries that present
rmartin> immutable interfaces?
nebbe> There is an enormous amount of linguistic evidence that our
nebbe> perception is based on things with firm boundaries. [ ... ]
And there are perhaps a billion people that have been raised in a
culture in which matter, not just things with firm boundaries, is
regarded as a rather nonsensical idea, and the notion of ``real world''
is considered a delusion fostered by abuse of language.
While many readers of these discussions will use a cognitive approach
based on the matter/spirit distinction, at least some will use a
rather different one, the form/mind one. Both are presumably workable,
and in the latter the idea of "things with firm boundaries" is
entirely nonsensical, for in it is impossible to define the concept of
a "thing".
Even in the western style matter/spirit cognitive structure, "things
with firm boundaries" are a difficult concept to use operatively. Is a
derivatives contract a "thing"? If so, what are its "boundaries"? And
what about the wind? And a theorem? Or an inference rule?
Positing some particular (and usually ill designed) ontology as the
basis of an engineering practice (program design) _might_ have
advantages.
However I have not seen any evidence yet that humans, or even humans in
one particular culture, share any given ontology, or that any such
ontology is suitable as a foundation for an engineering practice, or
even that in general founding a computational model on some human
cognitive model is a good idea.
In other words, the assumption that having programming methodologies or
computational models that resemble supposedly popular ontologies results
in easier/better/more fulfilling programming is totally unproven, even
if it sounds appealing.
And there are interesting hints that it is a silly idea: for the last
thing one normally wants to do is to have a program whose structure
resembles its problem domain. Mathematical models for examples are
based on a logic and have structures totally unlike those of the
problem domains they are applied to; fortunately, because they are
designed to be _much_ simpler, that's why one uses them.
By contrast the idea that clustering procedures according to whether
they access the same type representation is founded on a string of
fairly persuasive arguments and experiments.
t...@hplb.hpl.hp.com
Dave H. Griffiths (dh...@ajax.wda.disney.com) wrote:
|Logic is being squeezed into objects where it shouldn't be. A typical
|business use case is about a process.
There is no reason why a you cannot model a process using an object:
hardware engineers have been doing it for a long time! There are many
ways of doing that.
An example and mechanism that is simple to explain is to consider a
Fourier Transform process which consumes time-domain data and produces
frequency domain data. The obvious way of coding this leads to
statements such as
aFrequencyResponse := FFT of: aTimeSeries.
or
aFrequencyResponse = FFT.of( aTimeSeries );
Note that I am not necessarily advocating structuring the design that
way, since a dataflow structure might be more appropriate.
--
===============================================================================
The above are my own views, not the views of HP
Tom Gardner Hewlett Packard Laboratories, Filton Rd,
t...@hplb.hpl.hp.com Stoke Gifford, Bristol, Avon, BS12 6QZ, ENGLAND.
Fax: +44 117 9228920 Tel: +44 117 9799910 ext. 28192
===============================================================================
Greg Carter
b...@netcom.com (Bradley K. Sherman) wrote:
[snip]
>The central dogma of computers is: Increment
>the program counter. Until this changes, computer
>programming is inherently procedural.
But may we not layer abstractions upon this central dogma so that
programming becomes the method of communication most expediant to the
problem at hand?
----------------------
Thanks,
Greg Carter
Juergen Schlegelmilch
In article <bksDup...@netcom.com>, Bradley K. Sherman wrote:
>In article <31ec9...@info4.uni-rostock.de>,
>Juergen Schlegelmilch <schl...@Informatik.Uni-Rostock.de> wrote:
>>
>
>Why is this so? I have trained many young people to use
>structured techniques and they do not end up asking me
>questions about reality or the meaning of life and the
>psycholinguistics is limited to an occasional foray into
>Chomsky grammars.
My impression is that OO is something orthogonal to many areas,
including, but certainly not limited to, programming languages,
analysis, modelling, databases. It clearly has different appearance
in any of these, and people originating from different areas will
seldom find complete agreement on terms. Limiting OO to the
common base (whatever this is) seems unnecessary restrictive to
each of them, so they fight each other, trying to convince their
opponent of the apparent advantages that their understanding of
OO has, in their limited area of research. Everyone is correct,
but noone can rightly claim to speak for all.
>There is an article by B. Meyer in the current _IEEE Computer_
>warning OO designers *not* to get hung up on making objects
>in the system analogous to objects in the environment!
This is evidence of the different layers of abstract and the
different understanding of OO techniques in these layers. An
object for a programming language person seems to be an ADT,
while the modellers usually associate much more with this term.
My background is semantic data models, and because of the
similarity of language usage I was trapped into believing that
programming languages are implementations of these models. Well
they are not, at least from what I can tell with my knowledge
of C++, Eiffel, Smalltalk, and a few research prototypes. I
currently see two trends: one towards simplicity, in order to
make the languages understandable, the other towards higher
levels of abstraction, by including concepts of modelling. The
latter will hopefully narrow the gap between both areas, thus
reducing the confusion.
>The central dogma of computers is: Increment
>the program counter. Until this changes, computer
>programming is inherently procedural.
Ever come across functional or logic-based programming languages ;-))
Juergen
Patrick Logan
B., Burgin wrote:
>
> Is the Open/Closed principle as wonderful in practice as it sounds in theory?
> It seems, at least, that when changing the behavior of a module without changing
> the module itself, you cannot avoid having to do a lot of the work...
> such as test (revalidate) it, reason about it, etc...
>
> I'm not trying to speak against the Open/Closed principle, of course;
> I just think it sometimes makes extension of OO programs sound easier than it is.
True. But don't think of it as "changing the behavior of a module" as much
as "extending the set of objects that conform to an unchanging specification".
If the specification changes, then it is not truly conforming to the
Open/Closed Principle.
Also the alternative to "not modifying and retesting" is
"modifying and retesting" or perhaps "copying, modifying, and retesting".
What helps is having well-designed abstractions conforming to well-documented
contracts under the guidance of one or a few good architects and a
prototyping culture.
Andy Faibishenko
B.Burgin wrote:
: One day, Sheila hears about a new type of security (call it type X) and codes it up.
: Excited, Pete makes a new portfolio which has security X in it. His excitement turns to
: dismay, however, when he starts getting incorrect results on some of his portfolio
: evaluations. Further inspection reveals that there is a bug in the "value()" method
: for security X.
: What has happened is that code which was once running correctly (evaluatePortfolio),
: and which has not been modified (not even recompiled) is now producing erroneous
: results.
: OK, you will say, but that's normal; when there's a bug, there will be errors. True, but
: here the errors show up in code which hasn't even changed. At the least, this possibility
: means that code which is dependent on polymorphic methods must be retested every time
: new subclasses are added (i.e., every time the code is extended using the Open/Closed
: principle).
I don't see what the above has to do with the open closed principle.
If you have a function foo() that calls a function bar() and someone
introduces a bug into bar() that causes foo() to see erroneous results,
does this mean that every time bar() is changed, all the calls to it need
to be retested? Not typically! Usually you would unit test bar() to
make sure that all the preconditions and postconditions that applied
before the change still apply. Then you would be reasonably certain that all
modules (foo() included) will not see errors as long as the
preconditions, etc., are met by the caller.
Likewise, with polymorphism, you need to make sure that your derived
classes don't violate preconditions on your base classes(assuming the
polymorphism is implemented through inheritance) and fulfill base class
postconditions. I believe this is in line with the Liskov Substitution
Principle.
Andy Faibishenko
Metamor Technologies, Ltd.
1 N Franklin, #1500
Chicago, IL 60606
Piercarlo Grandi
>>> "brangdon" == "Dave Harris" <bran...@cix.compulink.co.uk> writes:
brangdon> Dave Nash <dn...@cerner.com> wrote:
dnash> Can someone give me a two-sentence definition of "Object
dnash> Oriented" (from a programming point of view) to settle a
dnash> discussion we're having here.
brangdon> Software based around, in order of importance:
brangdon> (a) Abstract Data Types;
brangdon> (b) dynamic polymorphism;
brangdon> (c) some form of delegation or inheritance;
brangdon> (d) automated memory management or garbage collection.
brangdon> This definition is actually so wrong it would be difficult to
brangdon> defend in a newsgroup like comp.object. (I hope Piercarlo
brangdon> Grandi is not reading this.)
Eheh. Too late. Here I am :-). Actually your description is not that
wrong. Compared to some that appear in famous books by celebrated
authorities it is quite better. It's not so much "wrong" as a bit too
colloquial, and then some details (even if important ones) are missing.
Let me try to rephrase what you said in a way I like a bit better:
Using an OO programming style means designing programs so that
(a) modules encapsulate exactly one ADT implementation each;
this practice must be _directly_ supported and enforced by the
language, which should also provide, for they have always been
important for most large programming tasks,
(b) static and dynamic ``polymorphism'', whatever that means;
(c) some explicit reuse mechanism like delegation or inheritance;
(d) automatic storage reclamation.
The main difference is that your points a) and b, c) and d) above are
not really on a continuum of importance as to OO-ness; only a) matters
as to OO-ness; b), c) and d) matter to most programming-in-the-large
situations, which are where OO is most usefully deployed.
Also, OO is indeed about ADTs, but in particular, and these seems
details but are important, _encapsulating_ _exactly one_ ADT
_implementation_ per _module_.
The "encapsulating" "exactly one", "implementation", and "module" bits
are what distinguish OO from other ADT-oriented approaches, and IMNHO
they should appear even in an informal definition; saying "(a) Abstract
Data Types;" is of course correct and points to the essence of the idea,
but it is too generic.
brangdon> Still, it is a useful real-world guide to the language
brangdon> features you want if you are to do
Agreed... (except for the ```real world'' idea of course :->).
brangdon> what most people call "object oriented programming".
Unfortunately this does not seem quite true. At times I despair: at
times it seems that sensible conceptualizations like yours are the
privilege of a minority.
Robert C. Martin
In article <4skk5...@svstch.ubs.ch>, Bernhard...@ubs.ch wrote:
> In article <rmartin-1707...@vh1-024.wwa.com>, rma...@oma.com
(Robert C. Martin) writes:
> |>
> |> The very first such principle was coined nearly a decade ago by Bertrand
> |> Meyer. It is named the Open/Closed principle. This principle states that
> |> a software module should be open for extension but closed for modification.
> |> This means that you should engineer each module in your application such
> |> that its behavior can be changed without modifying the module.
>
> Is the Open/Closed principle as wonderful in practice as it sounds in theory?
No. It is unachievable in the general case. However, it *is* achievable in
specific cases.
There is no way to close your code against every possible kind of change.
No matter what strategy you adopt, there will always be a class of changes
that forces that module to be modified. However, an experienced designer
learns to anticipate the kind of changes that are most likely to occur
in problem domain. And he will employ the OCP to close his modules
against those kinds of changes.
When the OCP is targeted against specific kinds of changes, it works
pretty well. But it is a gamble. The designer is gambling that he
really knows the kinds of changes that are going to take place. If
he is right, he wins. If he is wrong, he loses, and his modules must
be modified.
Thus, the efficacy of the OCP depends, almost entirely, upon the
experience and skill of the designers to predict change and close
modules. This is why the arguments that claim that OO allows newbies
to program like experts are in error.
> It seems, at least, that when changing the behavior of a module without
changing
> the module itself, you cannot avoid having to do a lot of the work that
you would
> have had to do if you had changed the module itself, such as test
(revalidate) it,
> reason about it, etc.
You certainly must retest at a certain level. However, since the
module was unchanged, you don't need to recompile it, regression test it,
unit test it, or release it. You *do* have to system test the whole
product, but what else is new?
[Several good examples of OCP failure elided.]
> I'm not trying to speak against the Open/Closed principle, of course; I
just think it sometimes
> makes extension of OO programs sound easier than it is. Anyway, here in
my group we have
> been greatly aided by the principles of OOD expounded by Robert Martin
in his book and
> comp.object postings.
All that you say is true. OCP will not save you in every case. But,
if carefully done, it *will* save you in the cases where *you* think
changes are likely to occur.
This is still software. There will still be bugs. There will still be
software disasters. OO is just a tool that mitigates a certain class
of problems.
Dave H. Griffiths
In article <4skk5...@svstch.ubs.ch> B. Burgin writes:
> What has happened here is that an attempt to extend
> modules via the Open/Closed principle has resulted in
> the need to analyze and reason about those modules. One
> or more of those modules will end up having to be changed.
> The coupling between the new code in the subclasses and
> the existing code which uses only the abstract interfaces
> cannot be ignored.
Nice example. When I first read Robert Martin's description of the
Open/Closed principle my jaw dropped open in disbelief. He seemed to be
talking about a dream world where changes arranged themselves nicely to
fit the pattern of your chosen design. All of which makes me wonder: are
there any large OO projects out there that were designed by Robert Martin
or Bertrand Meyer, and are there people reading this who are responsible
for the day to day maintainence of the system who can attest to the fact
that the principle works?
Dave
Robert C. Martin
In article <4sj52g$d...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave
H. Griffiths) wrote:
If there were an acceptable, reliable, and economically superior method
for building bridges out of marshmallow, then *yes* by all means I
would demand that the engineers to stop building the poor ones. More
to the point, I would hire only the good engineers.
Note that your argument was "its possible but its hard". That is a reasonable
description of OOD. The benefits are achievable, and the result is
economically superior in most cases, but it is initially harder.
So what's it going to be? Shall we choose to build economically
non-competative systems because they are easy? Or shall we build
economically competative systems even though they are difficult?
The choice is not straightforward. There are other issues such as time
to market etc. But when a mechanism exists that is economically superior
to another the user community will eventually demand its use, irrespective
of how hard it is.
Ell
Bradley K. Sherman (b...@netcom.com) wrote:
: Why is this so? I have trained many young people to use
: questions about reality or the meaning of life and the
: psycholinguistics is limited to an occasional foray into
: Chomsky grammars.
Perhaps that says something about the power of OO vs the less
so of Structured.
: There is an article by B. Meyer in the current _IEEE Computer_
: warning OO designers *not* to get hung up on making objects
: in the system analogous to objects in the environment!
I'd like to read this article. I don't think it reads as bad as you make
it sound.
: The central dogma of computers is: Increment
: the program counter.
Gee, I'll have to dust off my assembler books, then.
Elliott
b._burgin
|> Meyer. It is named the Open/Closed principle. This principle states that
|> a software module should be open for extension but closed for modification.
|> This means that you should engineer each module in your application such
|> that its behavior can be changed without modifying the module.
Is the Open/Closed principle as wonderful in practice as it sounds in theory?
It seems, at least, that when changing the behavior of a module without changing
the module itself, you cannot avoid having to do a lot of the work that you would
have had to do if you had changed the module itself, such as test (revalidate) it,
reason about it, etc.
Consider a hypothetical finance company, Ace Finance Inc., consisting of three
software engineers.
Sheila Security is in charge of the Security class and its
subclasses:
class Security
{
public:
virtual double value() = 0;
...
};
Sheila derives classes from Security (e.g., Stock, Bond, etc) for others in the
company to use.
Pete Portfolio puts together financial portfolios (a portfolio is a set of securities)
using Sheila's securities, and evaluates their total value:
double evaluatePortfolio(const Portfolio& p)
{
double value = 0;
while (Security* s = p.nextSecurity()) {
value += s->value();
}
return value;
}
Tom Tax, finally, is responsible for tax issues, such as checking the tax status of
different securities:
bool taxable(const Security& s)
{
...
if (s.value() fullfills some condition) return TRUE;
else return FALSE;
}
One day, Sheila hears about a new type of security (call it type X) and codes it up.
Excited, Pete makes a new portfolio which has security X in it. His excitement turns to
dismay, however, when he starts getting incorrect results on some of his portfolio
evaluations. Further inspection reveals that there is a bug in the "value()" method
for security X.
What has happened is that code which was once running correctly (evaluatePortfolio),
and which has not been modified (not even recompiled) is now producing erroneous
results.
OK, you will say, but that's normal; when there's a bug, there will be errors. True, but
here the errors show up in code which hasn't even changed. At the least, this possibility
means that code which is dependent on polymorphic methods must be retested every time
new subclasses are added (i.e., every time the code is extended using the Open/Closed
principle).
Back to Ace Finance. A week later, Sheila hears about yet another new type of security,
type Y, and goes ahead and implements it. When implementing the value function though, she
runs into a dilemma. It turns out that Y securities have two types of values (let's say,
for the sake of argument, an "adjusted value" which takes into account factors such as
accrued interest and inflation, and a "plain value"). She doesn't know which of the two
she should implement for the "value" method. In order to find out, she has to find out
who uses her "value" method, and what they really expect from it. Pete tells her that for
portfolio evaluation, he needs the plain value, whereas Tom the taxman tells her that
tax evaluation is always done using the adjusted value.
What has happened here is that an attempt to extend modules via the Open/Closed principle
has resulted in the need to analyze and reason about those modules. One or more of those
modules will end up having to be changed. The coupling between the new code in the subclasses
and the existing code which uses only the abstract interfaces cannot be ignored.
I'm not trying to speak against the Open/Closed principle, of course; I just think it sometimes
makes extension of OO programs sound easier than it is. Anyway, here in my group we have
been greatly aided by the principles of OOD expounded by Robert Martin in his book and
comp.object postings.
Bernhard Buergin
Union Bank of Switzerland
Piercarlo Grandi
>>> "GregC" == Greg Carter <Gr...@megaweb.com> writes:
GregC> b...@netcom.com (Bradley K. Sherman) wrote:
bks> The central dogma of computers is: Increment the program counter.
bks> Until this changes, computer programming is inherently procedural.
As brutally expressed as it is, I like it :-).
GregC> But may we not layer abstractions upon this central dogma so that
GregC> programming becomes the method of communication most expediant to
GregC> the problem at hand?
If by this you mean "Why not switch to the actor model?", the answer is
perhaps interesting, and perhaps useful, even if computational model
issues are not in any way related to the OO decomposition paradigm:
there are OO systems that are imperative, functional, logic, or actor
computational model based.
As such the following answer is striclty outside the charter of
comp.object, just as the long discussion on the ``traditional''
computational model was; however, given that many seem to mistake the OO
decomposition paradigm for the actor model of computation (or even for
object oriented modeling), illustrating the latter may help understand
the difference with OO as such.
The actor model is one possible abstract model of computation among
several based on the idea of ``intelligent data'' and of having
computational systems that resemble more closely the ``real world''
systems that they model, which are presumed to be conceptualized as set
of autonomous, active/passive entities.
It has not become popular for two reasons, perhaps mostly for
sociological reasons; but there are also one essential, and one merely
technological reason:
* The idea of having computational systems that mimic ``real world''
ones by expressing computations as patterns of message passing
between autonomous active computational entities is fundamentally
flawed _in the general case_ because:
- In general one wants computational structures to be
significantly simpler than what they model; the ``real world''
is often very complex, and one often enough is only interested
in a narrow, black box view. This is most apparent in the power
and convenience of mathematics: a set of equations often has no
resemblance whatsoever in structure to what they
model. Programming if often enough no different in this. There
is often enough, and actually as a rule, no intuitive link
between the structure of a program and that of what it models,
and fortunately so.
- Very often one wants to model purely mental constructs; these
often enough don't look at all like sets of autonomous
cooperating entities.
- The very notion of ``real world'' and what constitutes an
autonomous, crisply distinct entity in it, are extremely dubious
and controversial to say the least, and it is hard to give
operational meaning to them.
* A computational model based on the idea of cooperating, autonomous,
active objects, is really most appropriate to computer architectures
that are based on the ``intelligent memory'' idea, where each small
chunk of memory has its own autonomous processor and communication
devices.
However, almost all computers out there are, probably for very good
reasons, are based on the "Increment the program counter" von
Neumann style of architecture, and it is apparently hideously
expensive to simulate ``intelligent data'' architectures and
computational models on von Neumann style machines.
These two points, the essential and the technological, have probably
conspired to keep the imperative computational model, and thus
imperative OO systems, on top.
Fortunately OO is equally suited to imperative programming as to actor
programming: whether ADT implementations are encapsulated into procedure
closures or into intelligent data blocks, it's always OO decomposition.
Therefore, the summary answer to your original question:
GregC> But may we not layer abstractions upon this central dogma so
GregC> that programming becomes the method of communication most
GregC> expediant to the problem at hand?
is that both the method of communication is usually/often not the most
expedient, and that the layering is usually/often too expensive.
Naturally this does not means that there are cases where actor systems
(those based on OO + the actor model) are recommendable: if one wants to
do non-simplified-structure models of complex systems, and if one has
suitable implementation technology, swarms of actors are a good fit.
Distributed object technology is more like this: but then it occurs at a
level of scale and coarseness that is usually well beyond that of
``traditional'' programming tasks, and the switch to actor style
computational systems entails _large_, and often unexpected, changes in
approach.
Some interesting arguments as to this are contained in a recent cult
book, "Out of Control", where the central thesis is that large scale
computational systems will necessarily be actor based, and then they
will also necessarily be "out of control", that is self-regulating,
survival-oriented, in some ways ``alive''. This is probably a good
point, but it has nothing to do with OO or with programming tasks as we
know them today outside some research labs.
One interesting point in the book, just to mention how radically
different one can expect things to become, is that one can envision a
telephone system where exchanges and attached devices host swarms of
cooperating actors, that try to keep the system working and adaptable,
and that consume 95% of the computational power of the hardware on
which they run just to organize themselves and exchange messages, and
only 5% perhaps to service user requests.
Dave H. Griffiths
In article <4smokp$h...@news4.digex.net> e...@access1.digex.net (Ell)
writes:
> You don't have to do long term maintenance to see that the open/closed
> principle works. It is immediately apparent that it works during
> development when one creates new subclasses of a base class that work in
> all situations. As long as newly created subclasses require no more,
and
> provide no less than what the base class does, the open/closed principle
> holds. See the C++ FAQ book for more along these lines.
The principle could be restated, "make sure you know in advance exactly
how the requirements of the system will change in the future and structure
your design to take those changes into account".
Now where's that crystal ball...
Dave
James McKim
In article <4slpde$j...@louie.disney.com> dh...@ajax.wda.disney.com (Dave H. Griffiths) writes:
>In article <4skk5...@svstch.ubs.ch> B. Burgin writes:
>
>> modules via the Open/Closed principle has resulted in
>> the need to analyze and reason about those modules. One
>> or more of those modules will end up having to be changed.
>> The coupling between the new code in the subclasses and
>> the existing code which uses only the abstract interfaces
>> cannot be ignored.
>
>Open/Closed principle my jaw dropped open in disbelief. He seemed to be
>talking about a dream world where changes arranged themselves nicely to
>fit the pattern of your chosen design. All of which makes me wonder: are
>there any large OO projects out there that were designed by Robert Martin
>or Bertrand Meyer, and are there people reading this who are responsible
>for the day to day maintainence of the system who can attest to the fact
>that the principle works?
Robert has described such designs many times in the past and I'm sure
will speak for himself again. Bertrand Meyer is well known as the designer
of Eiffel and I would be very surprised if there is _any_ commercial
Eiffel system that _doesn't_ make heavy use of the open/closed principle.
I'll pass this along to a couple of folks and see if they care to comment.
FYI, I find it useful even in the small systems we design in courses here.
>
>Dave
Hope this helps,
-- Jim
--
*------------------------------------------------------------------------------*
Jim McKim (860)-548-2458 Teachers affect eternity. They can never tell
Internet: j...@hgc.edu where their influence stops.
b._buergin
In article <4slhmj$8...@nntp.interaccess.com>, an...@thymaster.interaccess.com (Andy Faibishenko) writes:
|> B.Burgin wrote:
|>
|> : OK, you will say, but that's normal; when there's a bug, there will be errors. True, but
|> : here the errors show up in code which hasn't even changed. At the least, this possibility
|> : means that code which is dependent on polymorphic methods must be retested every time
|> : new subclasses are added (i.e., every time the code is extended using the Open/Closed
|> : principle).
|>
|> If you have a function foo() that calls a function bar() and someone
|> introduces a bug into bar() that causes foo() to see erroneous results,
|> does this mean that every time bar() is changed, all the calls to it need
|> to be retested? Not typically! Usually you would unit test bar() to
|> make sure that all the preconditions and postconditions that applied
|> before the change still apply. Then you would be reasonably certain that all
|> modules (foo() included) will not see errors as long as the
|> preconditions, etc., are met by the caller.
|>
True enough. I guess my point is that the formulation of
pre- and post-conditions is trickier in the
polymorphic case, as they must be unambiguous not only for
one function called "bar", but for the "bar" method of all
current and future types. My second example showed how
the later addition of a new type suddenly revealed an ambiguity
in the original post-condition.
Patrick Logan
B., Buergin wrote:
>
> I guess my point is that the formulation of
> pre- and post-conditions is trickier in the
> polymorphic case, as they must be unambiguous not only for
> one function called "bar", but for the "bar" method of all
> current and future types.
Trickier? If you have one specification and ten implementations
corresponding to that spec, should that be considered "trickier"
than having ten somewhat similar specifications and ten
implementations each handled differently?
> My second example showed how
> the later addition of a new type suddenly revealed an ambiguity
> in the original post-condition.
Developing large software systems requires a willingness and
ability to correct previous work for the good of the whole
over the lifetime of the system. We do need better tools to
help manage the complexity of changes and testing, though.
Ell
Robert C. Martin (rma...@oma.com) wrote:
:I don't want to belittle simulation in any way. Nor do I want to insist
:that OO has nothing to do with simulation. However, I think that it is
:unwarranted to conclude that the key attributes of OO come from
:simulation. Indeed, Dahl and Hoare say this: "The dynamic system is
:constructed and understood in terms of high level concepts, which are in
:turn constructed and understood in terms of lower level concepts, and so
:forth. This must be relfected in the *structure* of the program which
:defines the dynamic system; in some way or another the higher level
:concepts will correspond to program components."
:So, it seems that Dahl
:and Hoare were more interested in the say that their techiques affected
:the *structure* of software in general.
They mention both aspects here, and do *not* say be more concerned with
stucture. Though you probably bolded it. Also there are analysis,
and architecture structures, not just code structures.
Elliott
Robb Nebbe
Piercarlo Grandi wrote:
>
> rmartin> Where is the evidence to support that humans percieve the world
> rmartin> as a set of static chunks with firm boundaries that present
> rmartin> immutable interfaces?
>
> nebbe> There is an enormous amount of linguistic evidence that our
> nebbe> perception is based on things with firm boundaries. [ ... ]
>
> And there are perhaps a billion people that have been raised in a
> culture in which matter, not just things with firm boundaries, is
> regarded as a rather nonsensical idea, and the notion of ``real world''
> is considered a delusion fostered by abuse of language.
The problem with using linguistic evidence is that you have to show that
it extends acrossed all linguistic groups in order to pretend that it says
anything valid about human perception.
Luckily this has been done for things like basic classifications levels (the
idea that all human languages have a word at a particular level of
abstraction, such as "tree" assuming that trees exist in their environment,
and that superordinate and subordinate levels of classification are much
more arbitrary.) The prevalent theory is that this is because all humans
share more or less the same perceptional capabilities. These basic classification
levels seem to be strongly based on form which would seem to be fairly firm.
It would seem that your foray into matter/spirit and form/mind distinctions
is at best irrelevant.
> While many readers of these discussions will use a cognitive approach
> based on the matter/spirit distinction, at least some will use a
> rather different one, the form/mind one. Both are presumably workable,
> and in the latter the idea of "things with firm boundaries" is
> entirely nonsensical, for in it is impossible to define the concept of
> a "thing".
If it is impossible to define the concept of a "thing" in the form/mind
cognitive approach then someone using this approach would not be able to
attach a meaning to "thing" and thus could not follow this particular
discussion. Am I the only one to whom this sounds plain silly?
Until someone posts saying "I'm sorry, I can't seem to understand this
"thing" concept; it must be due to my form/mind cognitive approach." I will
remain skeptical that it is relevant to this discussion.
> Even in the western style matter/spirit cognitive structure, "things
> with firm boundaries" are a difficult concept to use operatively. Is a
> derivatives contract a "thing"? If so, what are its "boundaries"? And
> what about the wind? And a theorem? Or an inference rule?
Are these examples from your own personal experience? Are you really unable
to come up with a sufficient definition for wind, theorems and inference rules?
People claim to have written software dealing with theorems and inference
rules so either they have sufficiently "firm boundaries" for there purposes
or they are perpetrating a giant hoax. I'm still waiting for Microsoft Wind to
come out :-)
> ...
> By contrast the idea that clustering procedures according to whether
> they access the same type representation is founded on a string of
> fairly persuasive arguments and experiments.
I have yet to see anybody in this thread pretend otherwise.
Robb Nebbe
Christopher Nagel,,,
>techniques such as Jacobson's "Controller" objects are so important. They
^^^^^^^^^^
>address this very issue.
>
Is he really responsible for the MVC paradigm??
Chris
Jon S Anthony
> Bradley K. Sherman (b...@netcom.com) wrote:
> : Why is this so? I have trained many young people to use
> : structured techniques and they do not end up asking me
> : questions about reality or the meaning of life and the
> : psycholinguistics is limited to an occasional foray into
> : Chomsky grammars.
>
> Perhaps that says something about the power of OO vs the less
> so of Structured.
I think it says something about how silly and pretentious a lot of OO
types have become. OO is not a branch of philosophy or something (or
if made to look as such by some zealous espousers, comes off less
interesting than the rubbish you can buy in the check-out lane). It
has and can give no insights into human nature, perception, cognition,
understanding, or the world. It's a tool/technique for organizing
software and constructing it. When relegated to this role it is a
very useful discipline. When some try to elevate it beyond this role,
it becomes embarrassingly silly.
/Jon
--
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178
Piercarlo Grandi
>>> "nebbe" == Robb Nebbe <ne...@iam.unibe.ch> writes:
nebbe> Piercarlo Grandi wrote:
rmartin> Where is the evidence to support that humans percieve the world
rmartin> as a set of static chunks with firm boundaries that present
rmartin> immutable interfaces?
nebbe> There is an enormous amount of linguistic evidence that our
nebbe> perception is based on things with firm boundaries. [ ... ]
pcg> And there are perhaps a billion people that have been raised in a
pcg> culture in which matter, not just things with firm boundaries, is
pcg> regarded as a rather nonsensical idea, and the notion of ``real
pcg> world'' is considered a delusion fostered by abuse of language.
nebbe> The problem with using linguistic evidence is that you have to
nebbe> show that it extends acrossed all linguistic groups in order to
nebbe> pretend that it says anything valid about human perception.
Exactly, but *you* have been trying to use linguistic evidence: my
comment was more in line with Robert Martin's original point, that was
not based on linguistic evidence. In fact I have mentioned explicitly
the notion of "abuse of language". That one can speak of trees as if
they were things with firm boundaries does not mean that they are, that
they are really perceived as such by anybody, or that if they are
everybody perceives them as such. And this just for things that arguably
*can* be perceived, unlike theorems or inference rules.
Actually the idea that we perceive a tree as a thing with firm
boundaries is to me entirely laughable: What are the firm boundaries of
a tree? Do they include the woodworms that have burrowed into the bark?
Do they include the morning dew that it collects?
I don't perceive any particular tree as having firm boundaries, for any
tree I have perceived mingles rather seamlessly into its environment.
I might even agree instead wiht a statement like:
Many people educated in the european way perceive the world as
containing also material things that have fuzzy boundaries and often
arbitrary definitions, and some of them are fully aware that this can
cause huge communication problems, for language can mask fundamental
differences in the perception of such boundaries and in the meaning of
such definitions.
As to the idea of fuzzy boundary, I hope it is merely sufficient to
mention the argument as to the length of the coast of Cornwall.
nebbe> Luckily this has been done for things like basic classifications
nebbe> levels (the idea that all human languages have a word at a
nebbe> particular level of abstraction, such as "tree" assuming that
nebbe> trees exist in their environment, and that superordinate and
nebbe> subordinate levels of classification are much more arbitrary.)
nebbe> The prevalent theory is that this is because all humans share
nebbe> more or less the same perceptional capabilities.
So far so good... :-)
nebbe> These basic classification levels seem to be strongly based on
nebbe> form which would seem to be fairly firm.
Well, this is totally unwarranted extrapolation.
nebbe> It would seem that your foray into matter/spirit and form/mind
nebbe> distinctions is at best irrelevant.
It would seem to me that your foray into linguistic evidence is at best
irrelevant: for we were discussing cognitive structures; and the
matter/spirit and form/mind ones are cognitive structures.
Your foray into lunguistic evidence is not about how we perceive the
world, but what kind of lexicon people use to describe elements of such
perceptions.
To somebody whose perceptions are based on the matter/spirit
distinction, the word "tree" evokes a thing, to somebody steeped in the
form/mind perception, the same word evokes a shape.
The lexicon can well be the same, but the meanings can be very
different. Disregarding this does not further analysis a lot.
pcg> While many readers of these discussions will use a cognitive
pcg> approach based on the matter/spirit distinction, at least some will
pcg> use a rather different one, the form/mind one. Both are presumably
pcg> workable, and in the latter the idea of "things with firm
pcg> boundaries" is entirely nonsensical, for in it is impossible to
pcg> define the concept of a "thing".
nebbe> If it is impossible to define the concept of a "thing" in the
nebbe> form/mind cognitive approach then someone using this approach
nebbe> would not be able to attach a meaning to "thing" and thus could
nebbe> not follow this particular discussion.
They could, if only to wonder what the fuss is all about. In fact, *I*
wonder what all the fuss is about. My education has been a classic
western one, but I can easily see its limits. The progress of science
has often been impeded by them -- and not only in particle physics.
nebbe> Am I the only one to whom this sounds plain silly?
Me too :-).
nebbe> Until someone posts saying "I'm sorry, I can't seem to understand
nebbe> this "thing" concept; it must be due to my form/mind cognitive
nebbe> approach." I will remain skeptical that it is relevant to this
nebbe> discussion.
Frankly I cannot quite understand this "thing" concept even in the
framework of the classic european matter/mind cognitive structure. In
effect I recall teachers during my early years always telling me to
avoid using the word and the concept of "thing" as being unworkably
generic and ill defined:
pcg> Even in the western style matter/spirit cognitive structure,
pcg> "things with firm boundaries" are a difficult concept to use
pcg> operatively. Is a derivatives contract a "thing"? If so, what are
pcg> its "boundaries"? And what about the wind? And a theorem? Or an
pcg> inference rule?
nebbe> Are these examples from your own personal experience?
Oh yes. Also yours, I'd guess.
nebbe> Are you really unable to come up with a sufficient definition for
nebbe> wind, theorems and inference rules?
Here you are arguing form the vantage point of ignoring that one can
define entities even if they are not elements of "our perception" which
"is based on things with firm boundaries."
One can come up with many a definition of wind, but can you tell me what
are its firm boundaries? Can you _perceive_ the wind? Or not just
perhaps some currents of air? Isn't the notion itself of "wind" a huge
mental construction?
And how can you perceive theorems and inference rules, even if they can
be defined precisely, and disregarding the issue of what are their firm
``boundaries''?
Still, the wind, theorems, contracts, inference rules belong to this
world, not to the next: but perhaps it is not the ``real world''. If the
world of finance, mathematics or the law ``real''? Are the concepts in
them based on perceptions of things with firmly defined boundaries?
Quite not: yet surely finance, mathematics, the law are part of our
experience in this ``real world'', and they do get modeled in OO
programs.
Yes, people model things like derivates contracts, the wind, and
theorems and inference rules in software; indeed even if these entities
are not perceivable, or don't have firm boundaries, they can be
represented by objects in a software system.
Thus my suspicion that modeling in software is not based on the abstruse
and abstract idea of perceptions based on things with firm boundaries,
but on modeling of whatever mental constructs the domain expert has
expressed.
nebbe> People claim to have written software dealing with theorems and
nebbe> inference rules so either they have sufficiently "firm
nebbe> boundaries" for there purposes or they are perpetrating a giant
nebbe> hoax.
Your first mistake here is to assume, begging the question, that if
something can be modeled then it has firm boundaries: this is manifestly
ridiculous. Because modeling is based on simplification, a lot of
modeling is based on _definining_ *arbitrary* boundaries where in our
perceptions they don't quite exist.
Your second mistake is lack of distinction between "things" you can
perceive and mental constructs like theorems and inference rules: for
your definition was that:
nebbe> There is an enormous amount of linguistic evidence that our
nebbe> perception is based on things with firm boundaries. [ ... ]
You should know you cannot perceive a theorem or an inference rule: you
can only conceptualize it. Mental constructs can be precisely defined,
yes: but then to claim that they can be perceived, and then perceived as
having firm boundaries, sounds the result of abuse of language.
As you remark, there is a lot of software exists that deals with classes
and objects that model purely mental constructs, not "things with firm
boundaries" on which "our perception" is based: so? Can it be OO?
The inability to see such all important distinctions ("ceci n'est pas un
pipe" and all that) seem stranegly to affect a number of posters in this
newsgroup.
nebbe> I'm still waiting for Microsoft Wind to come out :-)
That's the leading product of their PR-hype-and-vapourware division, and
perhaps it is their best selling one. :-)
Robert C. Martin
In article <4solej$r...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave
H. Griffiths) wrote:
[Regarding the Open Closed Principle.]
> What I was looking for was evidence that the principle had any value in a
> new problem domain likely to undergo change, or at least whether it had
> any more meaning than something banal like "you should always try and come
> up with a good design".
The meaning is a little bit more directed than: "Design well."
The direction that the principle gives is: "Design for change."
There are many other principles and patterns that are more explicit about
how that is done. One quick example: The "Abstract Server" pattern:
Abstract Server
Problem:
A client that users a server but should not depend upon that
server.
Context:
An OO language. The Server is accessed through the methods
of the Server class.
Solution
Create an abstract class (or interface) that represents the Server. Derive
the real server from it. Have the client refer to the abstract interface
rather than the actual server.
This pattern is the essence of the Open Closed Principle.
Robert C. Martin
> Dave H. Griffiths (dh...@ajax.wda.disney.com) wrote:
> : In article <4smokp$h...@news4.digex.net> e...@access1.digex.net (Ell)
> No, just that *any* subclass that requires no more, or promises no less
> than the base class, can be substituted for the base class.
>
That's another way of stating the "Liskov Substitution principle", which is
related to, and necessary for the Open Closed Principle.
Dave H. Griffiths
In article <dent-20079...@porcupine2-14.highway1.net.au>
de...@highway1.com.au (Andy Dent) writes:
> I don't know about their work, but I can attest to the
> principle working. The PowerPlant application framework,
> which is shipped with the Metrowerks CodeWarrior C++
> compilers, is a very recent framework. It makes good use
> of the principle in a number of areas. In particular,
> grid (table) classes are handled well with abstraction
> of selection, geometry, storage etc.
>
> Integrating our database, so the table draws straight from the database,
> was trivial because of the abstract storage interface. In contrast,
> integrating with MFC requires subclassing the entire grid class...
That's not quite what I had in mind. You're talking about a GUI toolkit
which is a pretty well understood domain by now. And the whole point of a
toolkit is that you shouldn't have to modify the original classes.
What I was looking for was evidence that the principle had any value in a
new problem domain likely to undergo change, or at least whether it had
any more meaning than something banal like "you should always try and come
up with a good design".
Dave
Bradley K. Sherman
In article <31EEBD...@ccm.hf.intel.com>,
Patrick Logan <patrick...@ccm.hf.intel.com> wrote:
>> b...@netcom.com (Bradley K. Sherman) wrote:
>>The central dogma of computers is: Increment
>>programming is inherently procedural.
>If by "procedural" you mean *imperative* then this is not
>so. There are such things as pure functional programming
>languages where order is not significant.
By procedural I mean procedural, i.e.
* A way of doing things
* A series of steps to an end
I do not understand this appeal to functional
programming languages which consist almost
entirely of functions with inputs on one
end, outputs on the and a procedure in
the middle.
--bks
Ell
: talking about a dream world where changes arranged themselves nicely to
: fit the pattern of your chosen design. All of which makes me wonder: are
: there any large OO projects out there that were designed by Robert Martin
: or Bertrand Meyer, and are there people reading this who are responsible
: for the day to day maintainence of the system who can attest to the fact
: that the principle works?
You don't have to do long term maintenance to see that the open/closed
principle works. It is immediately apparent that it works during
development when one creates new subclasses of a base class that work in
all situations. As long as newly created subclasses require no more, and
provide no less than what the base class does, the open/closed principle
holds. See the C++ FAQ book for more along these lines.
Elliott
Ell
: >
: > I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
: > where they mention the roots of OO in simulation. Where they emphasize
: > the modelling aspect of OO. Where they mention how OO support for
: > polymorphism enhances the ability to model, and simulate. It's like the
: > pragmatists are trying to deny the existence, and significance of Simula.
: Reread the original post Elliott. A "two sentence definition."; not
: a four sentence citing.
As I recall, your definition was as long if not longer than the above.
Further, the above *is* a definition if you allow your mind to see it.
Elliott
Ell
: Thus, far from emphasizing physical implementation at the expense of
: analysis and design; I emphasize it for the purpose of validating and
: reifying the analysis and design....
Heretofore, you have advocated coding with an optional architecture, and
without having done basic, essential analysis. If by the above you mean
prototyping to assess specific risks, and feasabilities, I have no problem
with that. But if you want to do production coding before having done
essential analysis of *all* critical uses cases in large projects, and all
primary, and some secondary use cases in small to medium scale projects
then you are still improperly wedded to a concept of project development
where physical coding is primary relative to everything else.
Elliott
Ell
: rmartin said:
: > > Also, if perception, understanding and communication are the primary
: > > benefits of OO; then it is not really a technology. Rather it is
: > > a language, medium, or even an art form.
OO has the things you mention above *and* as well it is a technology. How
are the things you mention incompatible with a technology? I think the
*best* technologies very much have the qualities you mention.
: > I would think it is all of these things in some ways depending on the
: > goal. TO illustrate: Is Mathematics a technology, a tool, a language, a
: > philosophy or an art form?
: >
: > My guess is that Mathematicians will tell you "all of the above",
: > depending on the context.
: Doubless this is true. However, it is quite debatable whether mathematics
: is "in line with human perception". Most people find mathematics quite
: impenatrable until they work hard to learn it. And the results of
: some mathematics (i.e. Quantum Mechanics) are even less intuitive than
: that the mathematics itself.
Mathematics is both "out" *and* "in" line with human perception. If I
have three stones, and add one, then I have four. 3 + 1 = 4. Very much
human perception, as I see it.
Elliott
Ell
: Griffiths) wrote:
: > In article <4s1sme$q...@news4.digex.net> e...@access1.digex.net (Ell)
: > writes:
:>>I suggest the reader see one of the books by Booch, Jacobson, or Rumbaugh
:>>where they mention the roots of OO in simulation. Where they emphasize
:>>the modelling aspect of OO. Where they mention how OO support for
:>>polymorphism enhances the ability to model, and simulate. It's like the
:>>pragmatists are trying to deny the existence, and significance of Simula.
:>where a lot of its problems lie. OO today is being used in areas where it
:>shouldn't. OO was developed as you say for modelling and simulation of the
:>physical world. Objects had an extended life, they interacted with other
:>objects, the logic was naturally embedded _in_ the object.
That's fine, but they should have the courtesy not to call what they do OO
then. They should call it Better Structured Approach,
Structured Approach with Polymorphism, whatever, but not OO.
:That OO has its roots in a simulation context is both debatable and
:irrelevant. Certainly the book "Structured Programming" which documents
:the OO aspects of Simula, does not stress "simulation" per se. Rather
:it stresses the fact that the OO constructs provide interesting and elegant
:new ways to structure the software and express the problem domain.
This book was cowritten by Dahl, a (the) major creator of Simula, the
first OO language.
Ron Kerr, and the H guy (sorry I forget) were there and they say the first
Simula projects had to do with simulation. And it is common knowledge that
simulation of a Norwegian firms's shipping operation was among the first,
if not the first major Simula project. You repeated this once yourself.
Elliott
Ell
WRONG ATTRIBUTON:
Robb Nebbe (ne...@iam.unibe.ch) wrote:
: P Grandi wrote:
^^^^^^^^^^^^^^^
: > While many readers of these discussions will use a cognitive approach
: > based on the matter/spirit distinction, at least some will use a
: > rather different one, the form/mind one. Both are presumably workable,
: > and in the latter the idea of "things with firm boundaries" is
: > entirely nonsensical, for in it is impossible to define the concept of
: > a "thing".
R Nebbe wrote:
: If it is impossible to define the concept of a "thing" in the form/mind
: cognitive approach then someone using this approach would not be able to
: attach a meaning to "thing" and thus could not follow this particular
: discussion. Am I the only one to whom this sounds plain silly?
You hit the nail on the barrel head!
Elliott
Robert C. Martin
In article <4slpde$j...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave
H. Griffiths) wrote:
> Nice example. When I first read Robert Martin's description of the
> Open/Closed principle my jaw dropped open in disbelief. He seemed to be
> talking about a dream world where changes arranged themselves nicely to
> fit the pattern of your chosen design. All of which makes me wonder: are
> there any large OO projects out there that were designed by Robert Martin
> or Bertrand Meyer, and are there people reading this who are responsible
> for the day to day maintainence of the system who can attest to the fact
> that the principle works?
You can download an article that I recently published in Object Magazine
entitled "OO Case Study" which describes a significant project that I and
my associates worked on.
You can get this from the 'freeware' section of my website.
The article shows both the successes and failures that we experienced. The
net result was positive, but was not without some significant pain.
I also suggest you download the paper entitled: "Principles of OOD" from
the same site. These are the principles we applied while working on the
project.
Believe me, I do not wan't to paint the picture of a "dream world"; but
I do thing these principles provide ways to lessen the frequency and intensity
of the nightmares.
Robert C. Martin
> Robert C. Martin (rma...@oma.com) wrote:
> :...
> : Thus, far from emphasizing physical implementation at the expense of
> : analysis and design; I emphasize it for the purpose of validating and
> : reifying the analysis and design....
>
> Heretofore, you have advocated coding with an optional architecture,
We've been through this. A *negotiated* architecture is not an
optional architecture. Once again, Elliott, I will ask you to find
the quote in any of my articles where I said architecture was optional.
If you can't do that, then let this dead dog rot in peace.
> and
> without having done basic, essential analysis.
Again, and for the Nth time, I have never advocated coding anything that
has not been properly analysed. Where we differ is only in that I recommend
that analyzed concepts should be coded before too many other concepts
are analyzed. I like to prove my concepts before building upon them.
That early code is more to test the concept than to implement it, but
if the code is appropriate for production I would not object. Indeed,
as the project continues, I would expect more and more such code to be
production quality.
Once more, find an article where I said that anyone should code an
un-analyzed concept. I you cant, then let this rotting dog disintegrate in
peace.
> If by the above you mean
> prototyping to assess specific risks, and feasabilities, I have no problem
> with that.
I mean more than prototyping, although prototyping is part of it. I mean
testing every concept before it is used as the basis for other concepts.
> But if you want to do production coding before having done
> essential analysis of *all* critical uses cases in large projects, and all
> primary, and some secondary use cases in small to medium scale projects
> then you are still improperly wedded to a concept of project development
> where physical coding is primary relative to everything else.
Who are you to call it "improper"?
Yes, I think that coding of analysed concepts should begin before all
the critical use cases are analyzed. I think coding should begin before
all the critical use cases have even been enumerated. I see no reason to
wait, and much danger in delaying. Coding something, and making it work
proves the concept and makes that concept a safe foundation to build upon.
That does not mean I advocate a lot of hacking, or that I thik "physical
coding is primary relative to everything else", it just means that I
don't trust analysis models until they have been tested.
If you disagree with this viewpoint, then we can discuss it. I like
discussing it. However, your persistent misquoting and your insistence
on pursuing those misquotes even after I have corrected you, have become
quite annoying.
Arthur Riel
>
> >The central dogma of computers is: Increment
> >the program counter. Until this changes, computer
> >programming is inherently procedural.
>
> problem at hand?
>
> ----------------------
> Thanks,
> Greg Carter
Absolutely. And since the central dogma of networks is to move a bit from point a to
point b don't start telling me about packet-based networks, TCP/IP, token ring,
ethernet stars, etc. The whole history of programming is filled with attempts to
control the increasing complexity by creating abstractions. The entire study of
data structures are a myth if you get down to the machine code level. Are you arguing
these things are not useful?
Arthur Riel
Andy Dent
>are
>there any large OO projects out there that were designed by Robert Martin
>or Bertrand Meyer, and are there people reading this who are responsible
>for the day to day maintainence of the system who can attest to the fact
>that the principle works?
I don't know about their work, but I can attest to the principle working.
The PowerPlant application framework, which is shipped with the Metrowerks
CodeWarrior C++ compilers, is a very recent framework. It makes good use
of the principle in a number of areas. In particular, grid (table) classes
are handled well with abstraction of selection, geometry, storage etc.
Integrating our database, so the table draws straight from the database,
was trivial because of the abstract storage interface. In contrast,
integrating with MFC requires subclassing the entire grid class...
Andy Dent, Product Architect, A.D. Software, Western Australia
OOFILE - "the cross-platform OODBMS that speaks c++"
ftp://ftp.highway1.com.au/pub/adsoftware/oofile/
http://www.highway1.com.au/adsoftware/oofile.html
Ell
: > principle works. It is immediately apparent that it works during
: > development when one creates new subclasses of a base class that work in
: > all situations. As long as newly created subclasses require no more,
: > and
: > provide no less than what the base class does, the open/closed principle
: > holds. See the C++ FAQ book for more along these lines.
: how the requirements of the system will change in the future and structure
: your design to take those changes into account".
No, just that *any* subclass that requires no more, or promises no less
than the base class, can be substituted for the base class.
Elliott
Dave H. Griffiths
In article <rmartin-1907...@vh1-026.wwa.com> rma...@oma.com
(Robert C. Martin) writes:
> You can download an article that I recently published in
> Object Magazine entitled "OO Case Study" which describes
> a significant project that I and my associates worked
> on.
>
> The article shows both the successes and failures that
> we experienced. The net result was positive, but was
> not without some significant pain.
I just read it and it was quite interesting. You were pretty upfront about
the problems you experienced. However, I don't think you can claim any
special credit for OO. With 18 vignettes to produce, practically any
approach would have resulted in a common framework of some sort. This is
the very stuff of programming: finding similarities and creating
abstractions.
Dave
Greg Carter
jsa@alexandria (Jon S Anthony) wrote:
[snip]
>OO is not a branch of philosophy or something (or
>if made to look as such by some zealous espousers, comes off less
>interesting than the rubbish you can buy in the check-out lane). It
>has and can give no insights into human nature, perception, cognition,
>understanding, or the world. It's a tool/technique for organizing
>software and constructing it. When relegated to this role it is a
>very useful discipline. When some try to elevate it beyond this role,
>it becomes embarrassingly silly.
I appreciate your efforts to keep our feet on the ground. However, I
think those of us who seem to be irritating you on this point are
actually suggesting something quite different than what you outline
here. Of course, I am speaking only for myself, but allow me to
present a rational for the position you apparently have
misinterpreted.
Suppose a friend tells you that they are interested in pursuing a
career in painting, and that they would like your advice on how to
proceed. What would you tell them? For my own part, I would tell them
to study the works of the masters - their use of color, brush strokes,
subjects, compositions, etc. Then imitate. After a time, their own
style should emerge and they will be a much better for having learned
from those who did it so well.
The same advise, I believe, would apply equally well for someone
pursuing, politics, swimming, architecture, blacksmithing or
securities investment. In my efforts to learn to play the trumpet, I
spent many hours listening to artist such as Gerard Swartzch, Louis
Armstrong, Miles Davis and Maurice Adre'. I listened, and then I
imitated. And while I have somewhat neglected my trumpet playing of
late, I fancy that at my best, I was a fairly decent trumpeter, owing
much of my achievement to the study and imitation the masters.
Now suppose a friend tells you that they are interested in pursuing a
career in systems design and would like your advice. Would you not
say, “study the works of the masters”? “Imitate their efforts”?
Certainly we have many masters in out profession upon which to choose
to base our own efforts. And certainly those masters have been more
than generous in the production of papers, books, lectures and
consulting companies with the goal of sharing their wisdom.
What I, and I believe others, are suggesting, is that there is one
master systems designer whose work, until the advent of Object
Technology, has gone largely unnoticed by us in the profession of
systems design. The systems of this designer easily handle the height
of complexity. The techniques employed are applied equally well to a
variety of problem domains. And the implementations are the essence of
robustness. Simply put, to the works of this designer, there are none
to compare. Of course, the designer of whom I speak is Nature.
In our efforts to become master systems designers ourselves, if we do
not heed the lessons and advice of Nature, if we do not hone our
technique through imitation of the technique of Nature, if we do not
draw upon the wisdom of systems design offered by Nature, then indeed,
we are on a fools errand.
Do I have my head in the clouds? Am I the one on a fools errand? Is
what I am presenting of any interest what so ever to people in our
profession? Maybe so. Maybe not. Time will tell. But I will make a
prediction. I predict that as our profession continues to mature, we
will inevitably align our methods with those of Nature. We cannot
escape it. It will come. And we will either embrace it and thereby
move quickly towards the achievement of our loftiest goals, or we will
be slowly dragged there, kicking and screaming, only to realize in the
end our foolishness and our waste of time.
And so, you say Object Technology “has and can give no insights into
human nature, perception, cognition, understanding, or the world.”
Perhaps not. And I don’t see where anyone has made that claim. On the
other hand, I firmly believe that human nature, perception, cognition,
understanding, and the world can give us a great deal of insight into
what Object Technology aspires to become.
Thanks,
G.Carter
P.S. My appologies to those to whom I had promissed to keep my mouth
shut under this heading.
----------------------
Thanks,
Greg Carter
Patrick Herring
rma...@oma.com writes in article <rmartin-1707...@vh1-024.wwa.com>:
>
> In article <4sha1j$8...@louie.disney.com>, dh...@ajax.wda.disney.com (Dave
> H. Griffiths) wrote:
...
> > We are also creating a whole realm of meta-objects. By meta-objects I mean
> > objects that have no direct parallel in the real world. We have to create
> > meta-objects because the processing has to go somewhere, and we've become
> > conditioned to thinking that "somewhere" is inside an object. Look at any
> > OO program and the vast majority of objects are meta-objects.
>
> I know those that would disagree with this statement. I, on the other hand,
> think that *all* objects are meta-objects. i.e. no object is a perfect
> representative of the real world. It does not scare me that many of the
> classes in a well designed OO system do not have real-world correspondents.
> This is one of Jacobson's most strongly made points. Stable systems are
> built from more than just real world entities.
It scares me (well, it puzzles me). How can there be 'unreal' entities in the
software if the software does something meaningful in the world? I suspect
that these unreal objects get invented by forcing a representation of the
world into the 'everything is an object' paradigm, which is itself unreal. Any
examples? (in pseudo-code not C++, big please.) Unless you mean simply a
classification of real properties which wouldn't be done in the
non-computerised way of solving the problem because of the different
engineering constraints in the two environments.
Statement of my position (which I think plenty of others hold, but which tends
to get buried amongst the hype): OO is a better (even, the best) form of
achieving structural modularisation and independence of processes, but is not
a complete form for expressing all possible problems & solutions. We also need
procedural/imperative semantics for representing actions & action sequences,
and declarative semantics for defining relationships (including between
objects - why specialise syntax for one particular declarative situation). The
goal is holistic clarity (by which I mean that it is clear not only what the
code does but also what it doesn't do) and so if you're having to go wide of
modelling the world then your paradigm(s) must be incomplete.
I doubt I could ever persuade many of my (dp programming) colleagues to
represent a process using objects, they'd just say 'why not just code the
thing straight?'. And they'd be right. '2+2' is NOT 'send to + message from a
number object with value attribute '2' to another one...'. Time and time again
I've had problems to solve (with people & programs) that existed solely
because the language couldn't express what the spec said.
Yours, Patrick
_____________________________________________________________________________
Patrick Herring, Primrose Hill, London, UK
I tend to eat my UUCP feed once a day, so replies can take two days
Jeffrey S. Brashear
Patrick Logan <patrick...@ccm.hf.intel.com> wrote:
>> > [OO vs. Procedural beer]
>>
>> Aren't we glad that when we want to open beer, there are only
>> 3 standard interfaces (pull tab, screw-off, and non-screw-off).
>>
>> And, only 2 of them are virtually indistinguishable. What's more,
>> if you accidentally mistake non-screw-off for screw-off, you
>> merely cut your hand... The bottle doesn't break and people don't die.
>>
<snip>
>The whole point of software is that it is a brand-new
>mechanism for relatively quickly building special-purpose machines.
>It should come as no surprise that there are an infinite variety
>of choices in software.
>
But if we already have three perfectly good mechanisms for opening a
beer ...
Maybe some hotshot who has read about container development will
decide that the appropriate standard will place the top on the bottom.
With enough marketing clout it could even become a defacto standard!
Jeff