Early Adopters say NOO
Bradley K. Sherman
Good articles in the October '97 _Computer_ with
theme of OO and reuse.
Some quotes from *Object Technology and Reuse: Lessons From Early
Adopters* (Fichman & Kemerer, pp.47-59).
OO is advertised as a fast development tool,
and as being more mature that it really is.
we got the impression that lots of reusable
components were available ... that part of it
turned out to be false.
It's hard to say what reuse really means. The
objects that get reused tend to be generic, not
domain specific--date, time, string classes. ...
Not many objects are common across systems ...
All-in-all I'd say that this issue of Computer is just
one of a series of publications that will serve notice
that OO is just a single tool, not the whole workshop,
and certainly not worthy of the hyperbole of the past
decade.
--bks
Scott A. Whitmire
Not so fast. If you take the use of OO to its logical
conclusion, that is, across the entire enterprise,
then eventually you will end up with a library of
business objects (actually collections of objects) that
are complete and cohesive. By complete, I mean they
meet the requirements from any point of view in the
business. By cohesive, I mean they implement one and
only one domain object. Given such a library, where
every domain object of interest to the company is
represented, you will see significant reuse. In such
a scenario, an application is nothing more than a set
of use cases threading through the inventory. We won't
maintain "applications" per se, but rather collections of
objects.
I don't see this scenario as having to be "developed" or
"designed." I see it as an inevitable result of the spread
of the use of object through the enterprise. Of course,
evolution is a (painfully) slow process, but I think it's
necessary in this case.
In other words, OO *will* live up to its hype. We just
need to be patient. Nothing I've heard in the hype is
inherently impossible, or even infeasible, which is
pretty amazing, frankly.
Scott A. Whitmire sco...@advsysres.com
Advanced Systems Research
25238 127th Avenue SE tel:(253)631-7868
Kent Washington 98031
Consultants in object-oriented development and software metrics.
Dave Griffiths
In article <62p7j1$p...@news9.noc.netcom.net>, Scott A. Whitmire
<URL:mailto:sco...@advsysres.com> wrote:
> Not so fast. If you take the use of OO to its logical
> conclusion, that is, across the entire enterprise,
> then eventually you will end up with a library of
> business objects (actually collections of objects) that
> are complete and cohesive. By complete, I mean they
> meet the requirements from any point of view in the
> business. By cohesive, I mean they implement one and
> only one domain object. Given such a library, where
> every domain object of interest to the company is
> represented, you will see significant reuse. In such
> a scenario, an application is nothing more than a set
> of use cases threading through the inventory. We won't
> maintain "applications" per se, but rather collections of
> objects.
Dream on. This will never happen for one simple reason: the
pace of technological change. We are living in a time of
continuous revolution. New operating systems, new languages,
new paradigms (eg the Web) mean that we never have the TIME
to benefit from a stable library of business objects. We're
constantly starting over again from scratch. And no object is
an island. They're embedded in their environment, and when the
environment changes, the objects are junked because the effort
involved in extracting them is too great. If you've got a
suite of objects written in Objective-C and making use of
distributed objects and EOF, it's just not worth the effort
converting them to Java/RMI/JDBC. So the wheel gets reinvented,
over and over again.
If there was a magic boomerang you could throw that would
make time stand still, then maybe a library of reusable objects
would make sense. But until then you're better off forgetting
about reuse and just churning out something usable as quickly
as possible.
Dave
Luther Hampton
Bradley K. Sherman wrote:
>
> Good articles in the October '97 _Computer_ with
> theme of OO and reuse.
>
> Some quotes from *Object Technology and Reuse: Lessons From Early
> Adopters* (Fichman & Kemerer, pp.47-59).
>
> OO is advertised as a fast development tool,
> and as being more mature that it really is.
>
> we got the impression that lots of reusable
> components were available ... that part of it
> turned out to be false.
>
> It's hard to say what reuse really means. The
> objects that get reused tend to be generic, not
> domain specific--date, time, string classes. ...
> Not many objects are common across systems ...
>
> All-in-all I'd say that this issue of Computer is just
> one of a series of publications that will serve notice
> that OO is just a single tool, not the whole workshop,
> and certainly not worthy of the hyperbole of the past
> decade.
>
Agreed. The reusability claims for objects from *project-to-project*
have been vastly overstated. I see things a little differently: I think
that the advantage of using object oriented techniques is reuse in the
small. What I mean is, properly employing OO OO design and coding
techniques should result in less program code. In any software
development process, less program code means fewer errors, (any other
advantages to an OOP approach aside). If you think about it, what's the
big deal in finding opportunities for polymorphism? You still have to
write different operations for each polymorphic class, but you get to
use the rest of the code untouched.
I am still optimistic about the chances of increased reuse form project
to project, but I think that that will have to wait until development
organizations are *very* sophisticated in OO techniques. I don't think
it should surprise anyone that there is no real reuse in the first few
object oriented developments. People are just starting to effectively
develop objects for their own use; it's a long way from there to being
foresighted enough to develop objects which can be effectively reused.
That will only come with experience.
In short, the immediate reuse reward in OO is *not* reuse of objects in
later projects, it is minimizing the code necessary to do the current
project by reusing internally to the maximum extent possible.
--
------------------------------------------------------------------
Luther Hampton Admit Nothing.
Interactive Objects, Inc. Deny Everything.
Alexandria, VA If They Persist, Make Accusations
------------------------------------------------------------------
Tim Ottinger
Scott A. Whitmire wrote:
>[snip]
> In other words, OO *will* live up to its hype. We just
> need to be patient. Nothing I've heard in the hype is
> inherently impossible, or even infeasible, which is
> pretty amazing, frankly.
I don't think anything ever lives up to its hype completely.
But I think that OO is more useful than this sound byte from
the magazine leads one to believe.
Addressing a few points:
> > OO is advertised as a fast development tool,
> > and as being more mature that it really is.
It's over 30 years old, and it is quite reliable when done
by people who know what it's supposed to do. Some languages
are less mature than others, and some components are newer
also, but the immature use of a thing doesn't prove the
technology to be immature. I'm guessing someone had a bad
project and is complaining publicly here.
> > we got the impression that lots of reusable
> > components were available ... that part of it
> > turned out to be false.
I'd love to know what languages the author was using and
what components they were trying to find. I'm overwhelmed
daily with the variety of C++ components, Python libs, and
Java components in the world.
> > It's hard to say what reuse really means. The
> > objects that get reused tend to be generic, not
> > domain specific--date, time, string classes. ...
> > Not many objects are common across systems ...
This is typically what happens when you are doing SA/SD or
IE style development in C++. You end up with the same problems
with reuse you had in C. The right way to do things will cause
you to build small 'abstract virtual machines' (packages) that
you can reuse in many places. Doing it wrong means you'll get
the standard "call tree" dependency structure, where everything
at the top depends on everything beneath it. It's a really sad
failure to manage dependencies if only your bottom-level stuff
is reusable. It proves you aren't doing OO well.
> >All-in-all I'd say that this issue of Computer is just
> >one of a series of publications that will serve notice
> >that OO is just a single tool, not the whole workshop,
> >and certainly not worthy of the hyperbole of the past
> >decade.
I would hope that it would prove that you can use OO naively,
and that it's a really powerful tool. If anyone thinks that
they can take the current staff from a non-OO language to an
OO language and all of the benefits will magically emerge like
"the great pumpkin" in the Peanuts cartoon series, they're
dead wrong.
But good analysis and OOD with an eye toward dependency
management will make things happen that would
not have happened with earlier methods.
>If you take the use of OO to its logical
> conclusion, that is, across the entire enterprise,
> then eventually you will end up with a library of
> business objects (actually collections of objects) that
> are complete and cohesive. By complete, I mean they
> meet the requirements from any point of view in the
> business. By cohesive, I mean they implement one and
> only one domain object.
I'd love to agree with you, but I don't. I think that it's
remotely possible that this will work out, but probably it
isn't a reasonable or necessarily a good goal.
I've found that even in a small set of applications for a
single company (a former employer) different applications
need different services from the same objects. If you put
methods and their supporting data into a class to support
application A, then application B (who doesn't need all of
those methods) will see them as baggage, and have to link
in methods and objects that it would otherwise not need.
Then B has special needs. If B pushes functionality into
the object, then now A takes on baggage from B. Then app
C comes along, and inherits baggage from A and B, and imposes
even more baggage on A and B.
Use some simple set theory here.
Say that Sa is the set of methods and data needed for an
object in application A.
Now consider Sb. Sb overlaps Sa somewhat, maybe entirely.
But it's likely in this case since application B is a
different application than application A that it will not
exactly match the set of Sa. The set of commonality is
a subset: Sa n Sb. If we make the object support the union
Sa U Sb, then we'll have one or both apps carrying unwanted
or at least unneeded baggage. You can bet that the third
view Sa n Sb n Sc will be the same size or smaller than
Sa n sB. The more overlapping sets we put on, the less
of Sa is actually universally needed. Eventually, if many
applications use Sa's object, the object will either become
a tiny wad (intersection) of data with accessors, or it will
become a huge mass (union) of baggage.
Instead, probably applications will use either different-but-
same-named objects, or they will use only the data from the
objects. Nobody likes to deal with other apps' baggage.
The problem is that they want to share concept, but not the
details. In order to manage this, perhaps they can share
some abstract base classes, but it's less likely that they'll
share objects.
Of course, the bottom-level (simple, independent) classes
like dates, times, sockets, and the like will probably be
sharable and will remain sharable.
Tim
Andy Dent
>I think
>that the advantage of using object oriented techniques is reuse in the
>small. What I mean is, properly employing OO OO design and coding
>techniques should result in less program code.
That's one good point.
I think the biggest "reuse opportunity" in OO is not inherently in the code
we write, but in the designs and analysis.
We are starting to have very high level design patterns and analysis
patterns (eg: Martin Fowler's "Analysis Patterns") recorded. These are rich
solutions which often make our software more adaptable. Many of these
patterns are a lot easier to write and maintain in an OO manner.
So, OO is a tool to simplify reuse of higher-level thinking.
--
Andy Dent, Software Designer, A.D. Software, Western Australia
OOFILE - Database, reports, GUI for c++ on Mac, Unix & Windows
http://www.highway1.com.au/adsoftware/
Scott A. Whitmire
In <ant24105...@om107.acorn.co.uk>, Dave Griffiths <dgri...@acorn.co.uk> writes:
>In article <62p7j1$p...@news9.noc.netcom.net>, Scott A. Whitmire
><URL:mailto:sco...@advsysres.com> wrote:
>
>> conclusion, that is, across the entire enterprise,
>> then eventually you will end up with a library of
>> business objects (actually collections of objects) that
>> are complete and cohesive. By complete, I mean they
>> meet the requirements from any point of view in the
>> business. By cohesive, I mean they implement one and
Your naysaying falls flat in the presence of techologies such
as COM and CORBA. Either of these will allow us to hook those
old objects into the new ones. By the way, the value of these
technologies is not at the binary level; it's at the
architectural level. With either one, it doesn't matter what
language the parts are written in, as long as the glue that
holds it together can translate.
Bradley K. Sherman
In article <6315vf$k...@news9.noc.netcom.net>,
Scott A. Whitmire <sco...@advsysres.com> wrote:
> ...
>Your naysaying falls flat in the presence of techologies such
>as COM and CORBA. Either of these will allow us to hook those
>old objects into the new ones. By the way, the value of these
Your use of the Future tense is noted. Present reports
of these technologies are less than scintillating.
Waiting for gOdOt,
--bks
Robert C. Martin
Bradley K. Sherman wrote:
>
> Good articles in the October '97 _Computer_ with
> theme of OO and reuse.
>
> Some quotes from *Object Technology and Reuse: Lessons From Early
> Adopters* (Fichman & Kemerer, pp.47-59).
[snip]
> All-in-all I'd say that this issue of Computer is just
> one of a series of publications that will serve notice
> that OO is just a single tool, not the whole workshop,
> and certainly not worthy of the hyperbole of the past
> decade.
>
Granted. OO is a single tool (or a set of closely related tools) that
do not desirve the hype of the past decade. However, that does not
mean that the the tools of OO are not good tools; they are.
This is something we have seen before, and we will see again. Some new
idea comes to the fore, and a bunch of people (whose scruples are
perhaps less than secure) think that they can make a lot of money
by jumping on the bandwagon. Then they force the bandwagon into
a frenzied acceleration by making a lot of ridiculous claims about the
superiority of the technique and the "Bold new age" that awaits
those who have true insight.
We saw this for the structured techniques (the era that invented the
term: "doing software 'right'".) and we have seen it for OO. We'll see
it again for the next good idea.
In the end, those that are wise will ignore the hype and get to the
real substance of the original good idea. OO has that original
substance. Using OO, software can be made to be more maintainable,
flexible and reusable than previously by providing a way of decoupling
modules more effectively.
--
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:
:
: This is something we have seen before, and we will see again. Some new
: idea comes to the fore, and a bunch of people (whose scruples are
: perhaps less than secure) think that they can make a lot of money
: by jumping on the bandwagon. Then they force the bandwagon into
: a frenzied acceleration by making a lot of ridiculous claims about the
: superiority of the technique and the "Bold new age" that awaits
: those who have true insight.
Believe me, the true "Bold New Agers" ain't doing it for the money. But
it *does* take the right insight to see the genuine essence of OO.
: In the end, those that are wise will ignore the hype and get to the
: real substance of the original good idea. OO has that original
: substance. Using OO, software can be made to be more maintainable,
: flexible and reusable than previously by providing a way of decoupling
: modules more effectively.
Ohhh Martin, he's such a kidder. ;-}
"Object-oriented programming. A program execution is regarded as a
physical model, simulating the behavior of either a real or imaginary part
of the world...The notion of a physical model should be taken literally."
~Computerized physical models
Madsen/Moeller-Pederson/Nygaard
Elliott
--
"The domain object model is the foundation of OOD."
"We should seek out proven optimal practices and use them."
See SW Modeller vs SW Pragmatist Central: http://www.access.digex.net/~ell
Scott A. Whitmire
In <345240DB...@dave-world.net>, Tim Ottinger <tott...@dave-world.net> writes:
>Scott A. Whitmire wrote:
>>[snip]
>> In other words, OO *will* live up to its hype. We just
>> need to be patient. Nothing I've heard in the hype is
>> inherently impossible, or even infeasible, which is
>> pretty amazing, frankly.
>
>I don't think anything ever lives up to its hype completely.
>But I think that OO is more useful than this sound byte from
>the magazine leads one to believe.
>
>Addressing a few points:
>
>> > OO is advertised as a fast development tool,
>> > and as being more mature that it really is.
Just a note. The lines with >> > are NOT mine...
>It's over 30 years old, and it is quite reliable when done
>by people who know what it's supposed to do. Some languages
>are less mature than others, and some components are newer
>also, but the immature use of a thing doesn't prove the
>technology to be immature. I'm guessing someone had a bad
>project and is complaining publicly here.
I agree.
>> > we got the impression that lots of reusable
>> > components were available ... that part of it
>> > turned out to be false.
>
>I'd love to know what languages the author was using and
>what components they were trying to find. I'm overwhelmed
>daily with the variety of C++ components, Python libs, and
>Java components in the world.
I agree here, too.
>> > It's hard to say what reuse really means. The
>> > objects that get reused tend to be generic, not
>> > domain specific--date, time, string classes. ...
>> > Not many objects are common across systems ...
>
>This is typically what happens when you are doing SA/SD or
>IE style development in C++. You end up with the same problems
>with reuse you had in C. The right way to do things will cause
>you to build small 'abstract virtual machines' (packages) that
>you can reuse in many places. Doing it wrong means you'll get
>the standard "call tree" dependency structure, where everything
>at the top depends on everything beneath it. It's a really sad
>failure to manage dependencies if only your bottom-level stuff
>is reusable. It proves you aren't doing OO well.
Reuse starts at the domain level and works inward. You cannot
get reuse at the code level without starting earlier.
>>If you take the use of OO to its logical
>> conclusion, that is, across the entire enterprise,
>> then eventually you will end up with a library of
>> business objects (actually collections of objects) that
>> are complete and cohesive. By complete, I mean they
>> meet the requirements from any point of view in the
>> business. By cohesive, I mean they implement one and
>> only one domain object.
>
>I'd love to agree with you, but I don't. I think that it's
>remotely possible that this will work out, but probably it
>isn't a reasonable or necessarily a good goal.
>
>I've found that even in a small set of applications for a
>single company (a former employer) different applications
>need different services from the same objects. If you put
>methods and their supporting data into a class to support
>application A, then application B (who doesn't need all of
>those methods) will see them as baggage, and have to link
>in methods and objects that it would otherwise not need.
>Then B has special needs. If B pushes functionality into
>the object, then now A takes on baggage from B. Then app
>C comes along, and inherits baggage from A and B, and imposes
>even more baggage on A and B.
I don't believe this is the case. In my own experience, this
"excess baggage" doesn't amount to much, when you limit
consideration to implementation of domain objects. I have found
excess baggage to be a problem when people implemented "wrapper"
objects for libraries of function calls (MFC and many of the
C++ frameworks fall into this category). Most of the time,
the functionality required by A, B, and C has significant
overlap.
>
>Use some simple set theory here.
I did. It's built into the model, and the measures of
completness and cohesion.
>Say that Sa is the set of methods and data needed for an
>object in application A.
>
>Now consider Sb. Sb overlaps Sa somewhat, maybe entirely.
>But it's likely in this case since application B is a
>different application than application A that it will not
>exactly match the set of Sa. The set of commonality is
>a subset: Sa n Sb. If we make the object support the union
>Sa U Sb, then we'll have one or both apps carrying unwanted
>or at least unneeded baggage. You can bet that the third
>view Sa n Sb n Sc will be the same size or smaller than
>Sa n sB. The more overlapping sets we put on, the less
>of Sa is actually universally needed. Eventually, if many
>applications use Sa's object, the object will either become
>a tiny wad (intersection) of data with accessors, or it will
>become a huge mass (union) of baggage.
Dynamic linking (the case in most of today's operating systems,
including Windows) makes this situation moot. You only get the
methods you call. Period. In addition, what you find is that
when you start with Sa U Sb, and then add Sc, that you add
fewer and fewer new features, until at some point, you add no
new features (this occurs when the object achieves full completeness).
>Instead, probably applications will use either different-but-
>same-named objects, or they will use only the data from the
>objects. Nobody likes to deal with other apps' baggage.
If the objects are different, why should they have the same
name? Take a global view of the domain. A part is a part is a part.
The situation you describe is the result of tunnel (or stovepipe)
vision. I've been there.
>The problem is that they want to share concept, but not the
>details. In order to manage this, perhaps they can share
>some abstract base classes, but it's less likely that they'll
>share objects.
The secret is to make the details transparent to the object.
I've seen the results of both ways of doing it. From experience,
I'd go with "my way" everytime. Actually, my experience is the
REASON it's "my way."
Bert Bril
Ell wrote:
> "Object-oriented programming. A program execution is regarded as a
> physical model, simulating the behavior of either a real or imaginary part
> of the world...The notion of a physical model should be taken literally."
>
> ~Computerized physical models
> Madsen/Moeller-Pederson/Nygaard
I've seen this definition coming up again and again. Can you imagine
that some definitions in books are:
* Valid for a certain context, or
* Plain wrong
The only books that are not subject to these shortcomings, are holy
books. Which are quoted time and again by the religious fanatics.
Quoting for other reasons than:
* acknowledging originality
* admiring the beauty
should never be part of any reasonable discussion. I think you are doing
neither here.
Therefore, let's stick to arguments and leave out tactics that belong to
marketing and religion. Like ridiculing, intimidation, repeating without
cause and so on.
Bert
-- de Groot - Bril Earth Sciences B.V.
-- Boulevard 1945 - 24, 7511 AE Enschede, The Netherlands
-- mailto:be...@dgb.nl , http://www.dgb.nl
-- Tel: +31 534315155 , Fax: +31 534315104
Patrick Logan
Bert Bril <be...@dgb.nl> wrote:
: Ell wrote:
: > "Object-oriented programming. A program execution is regarded as a
: > physical model, simulating the behavior of either a real or imaginary part
: > of the world...The notion of a physical model should be taken literally."
: >
: > ~Computerized physical models
: > Madsen/Moeller-Pederson/Nygaard
: I've seen this definition coming up again and again. Can you imagine
: that some definitions in books are:
: * Valid for a certain context, or
: * Plain wrong
For one thing, a simulation can be written in an object-oriented language
and in a procedural language. No one can prove that one of these
"simulates the behavior of the world" better than the other.
--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com
There is no such thing as a free variable.
R. Kerr
Bradley K. Sherman (b...@netcom.com) wrote:
> Good articles in the October '97 _Computer_ with
> theme of OO and reuse.
> Some quotes from *Object Technology and Reuse: Lessons From Early
> Adopters* (Fichman & Kemerer, pp.47-59).
> OO is advertised as a fast development tool,
> and as being more mature that it really is.
> we got the impression that lots of reusable
> components were available ... that part of it
> turned out to be false.
> It's hard to say what reuse really means. The
> objects that get reused tend to be generic, not
> domain specific--date, time, string classes. ...
> Not many objects are common across systems ...
> All-in-all I'd say that this issue of Computer is just
> one of a series of publications that will serve notice
> that OO is just a single tool, not the whole workshop,
> and certainly not worthy of the hyperbole of the past
> decade.
Disillusionment with OO is the natural consequence of studying the
hype rather than the history before rushing to adopt an unfamiliar
paradigm. OO is rooted in the need to master complexity, the primary
aim being to deliver systems of high quality which are faithful to
their purpose. There are obvious supplementary benefits including
flexibility and maintainability but reuse is not one of those which
come automatically.
Historically, reuse was not the major aim in applying OO. However,
the conceptual and structural modularity which characterises true OO
systems may provide a platform for reuse. Such a benefit cannot be
taken for granted. It depends to a very high degree on the
characteristics of the application domain and on the longer-term
perception and vision of the analysts and designers.
A further factor in disenchantment with OO may be that some of the
common vehicles provide only a compromise form of the paradigm,
so depriving it of some of its potential power.
Cheers....Ron
------------------------------------------------------------------------
Ron Kerr, Computing Service, Newcastle University, NE1 7RU, England.
Tel. +44 191 222 8187 Fax. +44 191 222 8765 E-mail r.k...@ncl.ac.uk
------------------------------------------------------------------------
R. Kerr
Patrick Logan (plo...@user2.teleport.com) wrote:
> For one thing, a simulation can be written in an object-oriented language
> and in a procedural language. No one can prove that one of these
> "simulates the behavior of the world" better than the other.
Perhaps not but it is possible to prove that one bears a closer
structural and behavioural resemblance to the real system than the
other and this has major implications for model development and
adjustment, as well as other issues.
Ell
Patrick Logan (plo...@user2.teleport.com) wrote:
: Bert Bril <be...@dgb.nl> wrote:
: : Ell wrote:
: : > "Object-oriented programming. A program execution is regarded as a
: : > physical model, simulating the behavior of either a real or imaginary part
: : > of the world...The notion of a physical model should be taken literally."
: : >
: : > ~Computerized physical models
: : > Madsen/Moeller-Pederson/Nygaard
: : I've seen this definition coming up again and again. Can you imagine
: : that some definitions in books are:
: : * Valid for a certain context, or
: : * Plain wrong
I bet you wish this one was wrong in general, eh?
: For one thing, a simulation can be written in an object-oriented language
: and in a procedural language. No one can prove that one of these
: "simulates the behavior of the world" better than the other.
Support, support, support. OOPL's _support_ object oriented modelling. In
particular most OOPL's support the creation, manipulation, and
polymorphism of objects.
Bradley K. Sherman
Man learned to fly when he stopped trying to flap wings.
Often there are processes in the real world that are
independent of the objects. From the perspective of the
space scientist amoebae, azaleas and apes are faces of
the same object. From the perspective of the cancer
researcher, the difference between two skin cells separated
by 1 mm is of ultimate importance.
It all depends on where you stand, and where you're going.
--bks
Robert C. Martin
R. Kerr wrote:
>
> Patrick Logan (plo...@user2.teleport.com) wrote:
>
> > For one thing, a simulation can be written in an object-oriented language
> > and in a procedural language. No one can prove that one of these
> > "simulates the behavior of the world" better than the other.
>
> structural and behavioural resemblance to the real system than the
> other and this has major implications for model development and
> adjustment, as well as other issues.
>
> Cheers....Ron
Aha! Now *that* is an interesting claim. I'd like to see it backed up
with some real data.
1. Is it really possible to prove that an OO program has a closer
behavioral and structural resemblance to the real system than
a procedural program has?
Certainly the behavioral part cannot be proved simply because I can
make a procedural program behave in exactly the same manner as an OO
program. So, the behavioral part of this claim is invalid.
How about structure. How can one measure the closeness of a software
system to a real world system? Can this be measured at all? Frankly,
I don't think so. For example, I can create a procedural simulation
of trains and passengers, that has train data structures and passenger
data structures and passenger_board, passenger_exit, train_start,
and train_stop functions. By what measurement criteria is this
farther away from an OO simulation that has train objects that have
'start' and 'stop' methods; and passenger objects that have 'board'
and 'exit' methods.
I don't believe that any measurement criteria can be found for
unambiguously determining whether an OO program or a procedural
program is "closer" to the real world system. Thus the second part of
this claim is invalid.
But let's suppose that we accept both claims above. Then the second
claim is that such a behavioral and structural similarity will have
major implications for "model development and adjustment".
What are these major implications? How can they be measured?
--
<<We are looking for good engineers>>
Tim Ottinger
> Therefore, let's stick to arguments and leave out tactics that belong to
> marketing and religion. Like ridiculing, intimidation, repeating without
> cause and so on.
For that matter, let's leave such tactics out of marketing and religion.
They're
the tactics messing those things up as well.
For that matter, they're the same problems that cause people to say NOO
to OO.
If we, as a programming community, were a lot less free with promises
and
sunshine, and a little more careful to be truthful and responsible with
our
remarkes (mine included) the whole industry would be better off and
there'd
be much less disillusionment in the world.
... and probably a lot more good software.
tim
R. Kerr
> >
> > Perhaps not but it is possible to prove that one bears a closer
> > structural and behavioural resemblance to the real system than the
> > other and this has major implications for model development and
> > adjustment, as well as other issues.
> Aha! Now *that* is an interesting claim. I'd like to see it backed up
> with some real data.
I don't think it is interesting at all and I was surprised I felt the
need to make it in this of all newsgroups.
> 1. Is it really possible to prove that an OO program has a closer
> behavioral and structural resemblance to the real system than
> a procedural program has?
> Certainly the behavioral part cannot be proved simply because I can
> make a procedural program behave in exactly the same manner as an OO
> program. So, the behavioral part of this claim is invalid.
It may produce the same results but the manner in which it does so may
appear quite different.
> How about structure. How can one measure the closeness of a software
> system to a real world system? Can this be measured at all? Frankly,
> I don't think so. For example, I can create a procedural simulation
> of trains and passengers, that has train data structures and passenger
> data structures and passenger_board, passenger_exit, train_start,
> and train_stop functions. By what measurement criteria is this
> farther away from an OO simulation that has train objects that have
> 'start' and 'stop' methods; and passenger objects that have 'board'
> and 'exit' methods.
The difference is the architectural framework within which these
things exist. Encapsulation and inheritance generally yield more
natural representations of the system being modelled, both physically
and conceptually, resulting in modularity and compartmentalisation
without the degree of fragmentation exhibited by procedural
simulations.
> I don't believe that any measurement criteria can be found for
> unambiguously determining whether an OO program or a procedural
> program is "closer" to the real world system. Thus the second part of
> this claim is invalid.
Comparisons of this nature are almost certain to be subjective but it
is difficult to dispute that if the entities of the real system
(objects, relationships, processes, interaction patterns, sub-systems,
etc.) have close counterparts in the model, then the model bears a
closer resemblance to the system than would be the case otherwise.
> But let's suppose that we accept both claims above. Then the second
> claim is that such a behavioral and structural similarity will have
> major implications for "model development and adjustment".
> What are these major implications? How can they be measured?
The implications are those which derive from quality of structure
generally. A model which perceptably resembles the system it
simulates is inherently more amenable to modification and development.
This property is important in all areas of software development but
particularly so in simulation when often the purpose is to conduct
experiments in order to predict the effects of different factors,
strategies, etc. in the real system.
Of course, all the above is predicated on analysts and designers who
are skilled in the proper application of object technology. It is not
sufficient just to just to write classes. I recollect the "paper" in
circulation many years ago in which it was asserted that "real
programmers" write FORTRAN in any language.
My further silence on this topic may be due to my impending holiday
..... or perhaps not!
Graham Perkins
John D Salt wrote:
> topmost layer? To my mind, the point is that O-O tools provide
> a virtual machine that is more easily mappable to "real" problems
> than that provided by traditional procedural methods.
Thanks for changing the thread name.
But you've moved the goalposts! Earlier point was about "simulation
of real world" and Robert Martin debunking idea that OO was
more "natural". Now if you're talking "real problems", it's a
slightly different argument. Yes, techniques, languages, and
tools that have come to fruition under the OO banner have
improved our ability to deal with such problems. Especially
as we develop our ability to develop computationally amenable
abstractions from that mess of the real world.
> >How about structure. How can one measure the closeness of a software
> >system to a real world system?.. create a procedural simulation
> >of trains and passengers, that has train data structures and passenger
> >data structures and passenger_board, passenger_exit, train_start,
> >and train_stop functions.
> What difference is there between the function "passenger_board" and
> the method "passenger.board"? It seems to me that your supposedly
> "procedural" approach has a very strong flavour of O-O about it!
This is a major problem when trying to contrast OO with Procedural.
It turns out that good modelling and good software engineering is
not *heavily* dependent on paradigm. In programming terms, object
orientation is not much more than a particular style of procedural
programming. Eg, making software resilient to change by localising
the effects of implementation decision is A Good Thing to do and
perfectly feasible with any paradigm. I find it much easier to
contrast Modula and UnModular programs than to clarify the divide
between Procedural and OO programs.
> It seems pretty obvious to me that the task would be
> easier in a language with good support for O-O.
It seems possible, but not obvious. There are plenty of things
happening in analysis and design that could make a bigger difference.
Robert was talking about a simulation, where for real world closeness
we'd need things like
- default concurrency of objects, easy to program with
- asynchronous and (selective) broadcast of messages
- selective receipt of messages
- pluggable message channels with fixed buffer & latency
- trigger-based processing
- continuous object awareness of passage of time
- ability of objects to move into different environments
- moving objects to keep themselves active by taking resources
with them or finding them locally (under own initiative)
if you're stuck with Smalltalk, Java, C++ etc. then most real world
kind of things have to be painfully implemented with crude
multithreading, monitoring/semaphoring, data sharing, interrupt
and signal programming, complex configuration management UUUGGGGHHHH
models the real world closely NOT.
> Pascal or Smalltalk is "closer" to normal human communication than
> MC68000 assembler is, so we "know" that O-O gives us higher-level
> constructs than a view that separates code and data.
Personally I am unable to identify my low vs. high level
discriminatory criteria. Perhaps it's just prejudice,
with everyone thinking that their favourite or most comfortable
language/environment is the highest level one.
Lots of people argue that Lisp, CLOS, and Smalltalk are
high level systems. Personally, I think they have a high
level of power by providing high reflective and incremental
development capabilities. It's easy to tweak your system
bit by bit until it provides highly focused and powerful
support for a particular domain you're interested in. But
I'd argue that the base systems themselves are fairly
simple and provide rather low-level constructs.
My prejudice also tells me that there are "level" differences
between Eiffel, Smalltalk, Java, and C++ that are much
to do with elegance of design, apposite library provision,
and incorporation of software engineering principles.
They do not all merit same "high level" status simply because
they are O-O.
> If it were
> not so, all talk of HOLs and LOLs would be gibberish.
well, most of it is!
> ... but I believe that
> Douglas Adams (yes, *that* Douglas Adams) was right when he said
> (at the 10th George Cherry Memorial Lecture) "Computers are machines
> for modelling the world".
Balderdash! They are machines for speeding up our banking operations,
booking our holidays, entertaining us, improving our automobile
performance, minimising the wages we pay to poor people, and ensuring
our deadly weapons kill as many people as possible. In some cases,
for certain periods of our technological history, it is convenient
to find abstractions of the real world and build computer models
of them. But that deosn't tell us what computers are for.
Ell
I had to add this quote of mine from another thread:
: Few other paradigms use abstractions that have both data and
: behavioral responsibilities, as OO does, both in analysis and
: design.
Abstractions combining behavior plus data more closely mirrors the nature
of "things" around us in both the real and imaginary world.
The support for such abstraction is another factor in how OOPLs make OO
programming more intutitive than using a non-OOPLs.
Elliott
Robert C. Martin
Graham Perkins wrote:
>
> This is a major problem when trying to contrast OO with Procedural.
> It turns out that good modelling and good software engineering is
> not *heavily* dependent on paradigm. In programming terms, object
> orientation is not much more than a particular style of procedural
> programming. Eg, making software resilient to change by localising
> the effects of implementation decision is A Good Thing to do and
> perfectly feasible with any paradigm. I find it much easier to
> contrast Modula and UnModular programs than to clarify the divide
> between Procedural and OO programs.
My definition of the difference between OO and procedural is as follows:
High level modules in a procedural program have hard dependencies on
lower level modules. i.e. high level modules call low level modules.
Thus, there are source code dependencies incoming to low level modules.
This makes the impact of changing a low level module very high since
it will have a direct affect upon the high level modules.
On the other hand, high level modules in an OO program are independent.
They either depend upon nothing, or they depend upon abstract
interfaces. Low level modules *depend* upon those same abstract
interfaces. Thus, there are no incomming dependencies upon low level
modules. In an OO program, nobody hangs a source code dependency upon
a low level module. Rather they hang it on an abstraction that the
low level module depends upon and implements.
I call this the "Dependency Inversion Principle" (DIP) And I state is
as follows: High level policies should not depend upon low level
implementations. Rather, low level implementations should depend upon
high level policies, or both should depend upon abstractions.
(For more about this principle, and others, see the 'publications'
section of my website.
--
Robert C. Martin
R. Kerr wrote:
>
>
> Encapsulation and inheritance generally yield more
> natural representations of the system being modelled, both physically
> and conceptually, resulting in modularity and compartmentalisation
> without the degree of fragmentation exhibited by procedural
> simulations.
This sounds good, but is it really accurate? What is "natural"
about inheritance and encapsulation? What is the definition of
"natural" in this case?
Some folks say that inheritance and encasulation (which we will
abbreviate as OO for the purposes of argument) fit more naturally
into the way humans think. I have seen no proof, or even evidence
of this claim. Indeed, I have seen people struggle very deeply to
get their minds around this concept that is supposed to be so
natural.
We could open up the old circle/ellipse problem again just to
demonstrate how unnatural *some* people find the rules of OO to be.
> [...]it
> is difficult to dispute that if the entities of the real system
> (objects, relationships, processes, interaction patterns, sub-systems,
> etc.) have close counterparts in the model, then the model bears a
> closer resemblance to the system than would be the case otherwise.
This I will grant you. However, if I have data structures and
functions (i.e. a structured design) that have close counterparts
in the real system; how is this "farther away" than an object oriented
design that has objects and methods that are close counterparts?
How can we measure that distance? How can we even describe it
qualitatively? What is the nature of the distance?
> > But let's suppose that we accept both claims above. Then the second
> > claim is that such a behavioral and structural similarity will have
> > major implications for "model development and adjustment".
>
> > What are these major implications? How can they be measured?
>
> The implications are those which derive from quality of structure
> generally. A model which perceptably resembles the system it
> simulates is inherently more amenable to modification and development.
Is this true?
Consider a model of a building. If the model is constructed with rivets
and welds, (very close to the real world system) it is going to be
hell to modify. But if the model is constructed with snap together
pieces (remember the old Girders and Panels playsets by Kenner) then
the model will be very easy to change, at the expense of being
farther from the real world system.
And that is the main point of software engineering. In software
engineering we try to create software that has the snap together parts,
instead of the rivets and welds that are present in the real system.
In that sense, it is the *differences* between the real world and the
model that make the structure of the software better!
Ell
: > For that matter, you do it using machine code, a universal
: > Turing machine, or a simple cellular automaton such as the Game
: > of Life. So what? Surely you wouldn't claim that any of these
: > are behaviourally closer to a "real" system at any but their
: > topmost layer?
: If they behave identically, then they have identical behavior. If that
: behavior is "close" to the real world system (whatever that means) then
: all of them are just as close from a behavioral point of view.
Right, there are no real world contextual facts. ;-}
: > To my mind, the point is that O-O tools provide
: > a virtual machine that is more easily mappable to "real" problems
: > than that provided by traditional procedural methods.
: An interesting viewpoint; but can it be demonstrated with any hard
: facts? What is it about OO that is "more easily mappable" to real
: problems? How much easier is it? Can the increase in "easiness" be
: measured in some way? And what are we comparing this "easiness" to?
: Structured analysis and design?
:
: I can tell you right away that a structured analysis and design is a
: lot quicker and easier to create than a good OO design.
Not necessarily true in my and others experience. A good structured
program takes planning and thinking. It may take more time than an OO
program that does the same thing.
: But that
: a good OO design has better maintainability characteristics than
: a structured design. If you accept this, then the "mapping" part
: of the prolem must be *harder* since it takes more time.
There is no law that because something is better it "must be *harder*".
Sometimes it's easier. To think see otherwise is self-flagellation.
: > >I don't believe that any measurement criteria can be found for
: > >unambiguously determining whether an OO program or a procedural
: > >program is "closer" to the real world system. Thus the second part of
: > >this claim is invalid.
: > I don't believe that sensible measurement criteria can be found for an
: > awful lot of things, and, yes, this is probably one of them. Still,
: > I have a strong gut feeling that Ron is right. Just as we know that
: > Pascal or Smalltalk is "closer" to normal human communication than
: > MC68000 assembler is
: Is this something we "know", or just something we assume? In fact, *is*
: smalltalk closer to human communication? Frankly I think assembler and
: smalltalk are both equidistant from real human communication. One is
: simply more convenient than the other; but no closer to humanity.
: And the reason it is more convenient has to do with its density of
: expression not its closeness to human communication.
:
: So, does OO support models that are closer to the real world system?
: I don't think so.
The fact that Smalltalk and other OOPL's support objects and polymorphism
that are manifest in real world systems has nothing to do with it. ;-}
Ell
: > Using a non-OOPL for simulation, bites because there is no _support_ for
: > achieving generalization/specialization, and there is no support for
: > exploiting the polymorphism resulting from generalization/specialization.
: Absolutely correct. Using a non-OOPL for *anything* bites for exactly
: that
: reason. And what is that reason? If we can create generalizations,
: then we
: can create modules that are general. Those general modules can specify
: high
: level policies that do not depend upon the specializations. (i.e. the
: Dependency Inversion Principle (DIP)).
Rather than name this something that good programmers avoided in the past,
why not call it the Abstract Dependency Principle (ADP)? Details should
often physically depend on abstractions. And not always for physical, but
for conceptual reasons.
: Without an OOPL, those functions
: that
: represent policy will have to deal with the fact that there are
: different
: specializations. (Usually with ugly if/else or switch statements). Or
: they
: will have to create some kind of jump table (poor man's OO).
: You are right, Elliott, using a non-OOPL bites! It bites because we
: have
: to deal with the exceptional conditions every where the generality
: appears.
: Whereas in an OOPL we can specify all the exceptions in one place and
: allow
: the generalities to be ingorant of them.
:
: None of which has anything at all to do with a real world system that
: does not
: attempt to hide the exceptions from the generalities.
Commonality, which Generality represents, really does exist amongst a
category of similar things. And yes a "model" and "modelling" are not the
*exact* same thing as that being modelled. Otherwise why model?
: > : I don't believe that any measurement criteria can be found for
: > : unambiguously determining whether an OO program or a procedural
: > : program is "closer" to the real world system. Thus the second part of
: > : this claim is invalid.
: > It is not a matter of mathematical type measuring per se, but of realizing
: > the easier and more intuitive way that OOPL's model actually existing
: > system behavior,
: You are using quantitative terms: 'easier' and 'more intuitive'.
No they are qualitative terms.
: But
: are not telling us how we can quantify how much easier or how much more
: intutive. What part is easier? What do you mean by "more intutitive".
We generally let the domain experts and users decide. And because OOD
should mirror, or embed the major logical relationships and objects in the
domain object model and use cases, then they also decide to that extent
what is intuitive in program OOD. This tends to make maintenance more
intuitive. Initial programmers often aren't around later, and the logical
domain model should be more stable then specific use cases.
: These terms are great when you want to sell something, but don't work
: very well when you want to explain something.
Most domain experts and users can agree on what is intuitive. And if not
then I'll do what is intuitive to *my* clients, for the same reasons I
outlined in my last paragraph.
Jay Martin
Robert C. Martin wrote:
>
> Graham Perkins wrote:
>
> >
> > This is a major problem when trying to contrast OO with Procedural.
> > It turns out that good modelling and good software engineering is
> > not *heavily* dependent on paradigm. In programming terms, object
> > orientation is not much more than a particular style of procedural
> > programming. Eg, making software resilient to change by localising
> > the effects of implementation decision is A Good Thing to do and
> > perfectly feasible with any paradigm. I find it much easier to
> > contrast Modula and UnModular programs than to clarify the divide
> > between Procedural and OO programs.
>
>
> High level modules in a procedural program have hard dependencies on
> lower level modules. i.e. high level modules call low level modules.
> Thus, there are source code dependencies incoming to low level modules.
> This makes the impact of changing a low level module very high since
> it will have a direct affect upon the high level modules.
>
> On the other hand, high level modules in an OO program are independent.
> They either depend upon nothing, or they depend upon abstract
> interfaces. Low level modules *depend* upon those same abstract
> interfaces. Thus, there are no incomming dependencies upon low level
> modules. In an OO program, nobody hangs a source code dependency upon
> a low level module. Rather they hang it on an abstraction that the
> low level module depends upon and implements.
I think you are gobbling up too much of procedural and
placing it in completely in OO (or maybe you mean
"top-down procedural") . Are abstract data types solely
in OO? Any bottom-up "procedural" design will abstract the
subsystems into abstract data types (encapsulation being
directly supported or not) that can be swapped at compile
time. What I think OO contribution is to add dynamic polymorphism,
i.e you can switch between abstract data type implementations
during runtime and do it without using tedious all inclusive
super "union" abstract types with a bunch of case statements, etc.
Jay
Bradley K. Sherman
In article <638g1a$e3k$1...@news2.digex.net>, Ell <e...@access2.digex.net> wrote:
> ... I.e all
>categories of Vehicles share certain characteristics, and behaviors. ...
I wonder if one can really enumerate shared characteristics and
behaviors of a toboggan, a cruise missle, and the Titanic.
Or perhaps you meant something like "We may regard fiction ...
as the vehicle of a certain philosophy of life," (J.B. Priestly)
or do you mean the 99% inert substances in pharmaceuticals that
are vehicles for the active molecule.
--bks