Anti-patterns
Richard J Kucera
Aren't "anti-patterns" just another way of locating power and
responsibility
outside the developers responsible for getting the results--delivering
what's required
and delivering on time, to quote Van Morrison? Lot's of methodology
immediately
focuses you on "process" and different ways to blame failure on forces
external to
the developers. And the AntiPatterns book is an elaborate enumeration
of
different forces to blame...and how to elaborately lament "what's
happening to you"
and "how to get out of it"...it would seem to create more powerlessness
to deliver and
lack of communication rather than doing what's required and
communicating
real status & progress in a down-to-earth manner. Is there an "Earthy
Anti-pattern"?
Why even think about patterns? What about that?
Andy L. Czerwonka
I think you're missing the point about aptterns in general. Patterns (i'll
use the term in the context of the GOF book) allow software developers,
designer, engineers, whomever to reuse designs that work. The GOF simply
assigned names to designs that have been reused in software for many
years. They also talk about why a specific pattern works, why it applies
to certain problems and when to use them. Anti-patterns, OTOH, are
descriptions of patterns that are seen in the industry that don't work.
They describe why a specific pattern does NOT work. IMHO, the whole
pattern movement, even in its infancy, has improved the quality of
software.
--
Andy L. Czerwonka
Chief Architect
CORBATECH Inc.
__mm_(õ¿õ)_mm__
>Richard J Kucera wrote:
>
[snip]
>I think you're missing the point about aptterns in general. Patterns (i'll
>use the term in the context of the GOF book) allow software developers,
>designer, engineers, whomever to reuse designs that work. The GOF simply
>assigned names to designs that have been reused in software for many
>years. They also talk about why a specific pattern works, why it applies
>to certain problems and when to use them. Anti-patterns, OTOH, are
>descriptions of patterns that are seen in the industry that don't work.
>They describe why a specific pattern does NOT work. IMHO, the whole
>pattern movement, even in its infancy, has improved the quality of
>software.
>
Andy:
You express an opinion for that last sentence, but have you any pointers to
research which shows evidence that quality has improved as a result of
patterns? Or is too early to tell? etc.
TIA
>--
>Andy L. Czerwonka
>Chief Architect
>CORBATECH Inc.
>
>
akmal
--
email: akmal(at)bigfoot(dot)com
http://www.bigfoot.com/~akmal/
Tony
> >IMHO, the whole
> >pattern movement, even in its infancy, has improved the quality of
> >software.
Realize that "patterns" is just a fad term for a concept/way-of-thinking
as old as mankind and nothing new at all. Caveman ties a stone on a
stick and calls it the "hammer" pattern. Patterns are nothing more than
designs and inventions that may have broader applicability, don't get too
bogged down in it. If you've ever built anything from scratch before at
all, you've probably used patterns and many more than the few that have
been popularly written about in computer texts. If you see a design
that's useful to you, then use it and/or catalog it in your brain or
elsewhere.
When in doubt, go back to first principles. There's not as much "new"
technology as the industry would have you believe. There is plenty of
marketing hype though so beware of the trend that attempts to coin
common sense for profit.
Tony
Neil MacMullen
Tony wrote in message ...
>In article <36176ecc...@news.erols.com>, e...@access.digex.net
>says...
>> Hear, hear! Why do some people think that speaking favorably of
>> anything in software engineering automatically means you are about to
>> go into an apoplectic fit of wild-eyed, mouth foaming praise, silver
>> bullet worship, hosannas, and glory hallelujahs.
>
>Er.. maybe because 90%+ of the information you receive daily is useless
>marketing hype?
>
Does anyone else remember 'The Last One' so called because it would
be 'the last program you will ever buy'. As I recall it was the beginning
of the '4GL' craze.
Neil
Ell
>I think you're missing the point about aptterns in general. Patterns (i'll
>use the term in the context of the GOF book) allow software developers,
>designer, engineers, whomever to reuse designs that work. The GOF simply
>assigned names to designs that have been reused in software for many
>years. They also talk about why a specific pattern works, why it applies
>to certain problems and when to use them. Anti-patterns, OTOH, are
>descriptions of patterns that are seen in the industry that don't work.
>They describe why a specific pattern does NOT work.
Sounds useful.
>IMHO, the whole
>pattern movement, even in its infancy, has improved the quality of
>software.
Hear, hear! Why do some people think that speaking favorably of
anything in software engineering automatically means you are about to
go into an apoplectic fit of wild-eyed, mouth foaming praise, silver
bullet worship, hosannas, and glory hallelujahs.
Are their lives so empty that they get joy out of being wet blanket
promoters of the sullen and melancholy? Have they been so badly
duped in the past that they feel obligated to attempt to squash and
crush even the smallest good thoughts about a technique, tool, or
concept?
It certainly seems that way.
Though ideally people should find out about things in the most
accurate manner possible, I would rather people know about useful
techniques, tools, or concepts with a bias toward being overly
enthusiastic than for them to be prematurely restrained, held back,
put in check, and reined in. You know like the joy and happiness that
kids have when they find out about the relativistic twin paradox, or
when they hear about apparently faster than light sub-atomic particle
communications, or when they find out that the female praying mantis
bites her mates head off and then copulates with the squirming body.
Elliott
--
:=***=: VOTE NO TO MODERATION! :=***=:
CRAFTISM SHOULD NOT USE USENET RESOURCES TO AVOID CRITICISM!
MODERATORS SHOULD NOT HAVE LIFETIME TERMS!
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
Study Phony Crafite OO vs. Genuine OO: http://www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
Tony
> anything in software engineering automatically means you are about to
> go into an apoplectic fit of wild-eyed, mouth foaming praise, silver
> bullet worship, hosannas, and glory hallelujahs.
Er.. maybe because 90%+ of the information you receive daily is useless
marketing hype?
Tony
Ell
>Tony wrote in message ...
>>
>>In article <36176ecc...@news.erols.com>, e...@access.digex.net
>>>
>>> Hear, hear! Why do some people think that speaking favorably of
>>> anything in software engineering automatically means you are about to
>>> go into an apoplectic fit of wild-eyed, mouth foaming praise, silver
>>> bullet worship, hosannas, and glory hallelujahs.
>>Er.. maybe because 90%+ of the information you receive daily is useless
>>marketing hype?
>Does anyone else remember 'The Last One' so called because it would
>be 'the last program you will ever buy'. As I recall it was the beginning
>of the '4GL' craze.
OK, but anyone who has been in the field for 4 to 5 years knows how to
separate the truly hip from the hype. Any manager or team lead who
falls for marketing hype doesn't deserve the job.
Albert Ratzlaff
Tony wrote:
> > >Richard J Kucera wrote:
> > >IMHO, the whole
> > >pattern movement, even in its infancy, has improved the quality of
> > >software.
>
> Realize that "patterns" is just a fad term for a concept/way-of-thinking
> as old as mankind and nothing new at all. Caveman ties a stone on a
> stick and calls it the "hammer" pattern. Patterns are nothing more than
> designs and inventions that may have broader applicability, don't get too
> bogged down in it. If you've ever built anything from scratch before at
> all, you've probably used patterns and many more than the few that have
> been popularly written about in computer texts. If you see a design
> that's useful to you, then use it and/or catalog it in your brain or
> elsewhere.
>
> When in doubt, go back to first principles. There's not as much "new"
> technology as the industry would have you believe. There is plenty of
> marketing hype though so beware of the trend that attempts to coin
> common sense for profit.
>
> Tony
Right. For example, story writers and movie people have used patterns for
ages. Never heard about the "Boy meets girl, boy falls in love with girl,
etc.etc." pattern? I've heard it said that there are only a few basic
patterns for story arguments. You know the pattern, you know how it ends.
Regards
Albert Ratzlaff
Bob Binder
Let me speak to this as a "convert" of sorts. I suspected patterns
where a lot of eyewash when I first heard the buzz -- it really
seemed like old wine in new bottles, yet another software hype-fest
craze where form dominated substance. I was deeply suspicious that
they were an excuse for sloppy thinking and a fig leaf for hacking.
The fact that a lot of "me-too" stuff appeared -- calling any x
pattern because pattern = good = $$ -- didn't help. We've seen
that before (Once upon time, the brave little object set out to save
the world . . .)
However, after careful study, I realized there was value not only
in what some patterns expressed, but in the way they structured
the presentation. Information results from organization. Patterns make
their writer answer a fixed set of basic questions, and in doing
this, the writer must present a complete and concise solution to
a specific class of problems. The expression is *qualitative* and
asks the pattern writer to explain "why" some x is a good thing.
This turns out to be much harder than it seems. I work in testing
and have adapted patterns to express test design strategies. I have
written about two dozen test design patterns. Although I'd previously
written detailed explanations with examples of many different test
strategies, recasting them as patterns sharpened my focus and
generally improved the whole thing. I think it also better serves
the reader by providing the same handles on different concepts.
What I also confirmed is that patterns aren't the best way to
express many subjects -- developing and explaining a conceptual
framework, telling a story (what happened), explaining how
a particular technical works, or presenting the theory that supports
an approach.
______________________________________________________________________________
Bob Binder http://www.rbsc.com RBSC Corporation
312 214-3280 tel Software Engineering 3 First National Plaza
312 214-3110 fax Process Improvement Suite 1400
rbi...@rbsc.mapson.com (remove .mapson to mail) Chicago, IL 60602-4205
Tony wrote in message ...
Tony
says...
> "Neil MacMullen" <znma...@zistar.zca> wrote:
>
> >Tony wrote in message ...
> >>
> >>>
> >>> Hear, hear! Why do some people think that speaking favorably of
> >>> anything in software engineering automatically means you are about to
> >>> go into an apoplectic fit of wild-eyed, mouth foaming praise, silver
> >>> bullet worship, hosannas, and glory hallelujahs.
>
> >>Er.. maybe because 90%+ of the information you receive daily is useless
> >>marketing hype?
>
> >Does anyone else remember 'The Last One' so called because it would
> >be 'the last program you will ever buy'. As I recall it was the beginning
> >of the '4GL' craze.
>
> OK, but anyone who has been in the field for 4 to 5 years knows how to
> separate the truly hip from the hype. Any manager or team lead who
> falls for marketing hype doesn't deserve the job.
Well by that criteria, most IS managers would be out of a job. (And 4-5
yrs is still kinda "green" if you ask me.. especially if still in their
20's).
Tony
Tony
> However, after careful study, I realized there was value not only
> in what some patterns expressed, but in the way they structured
> the presentation. Information results from organization. Patterns make
> their writer answer a fixed set of basic questions, and in doing
> this, the writer must present a complete and concise solution to
> a specific class of problems. The expression is *qualitative* and
> asks the pattern writer to explain "why" some x is a good thing.
I never said that there wasn't value in it, but rather that the
marketeers just picked up on things "our kind" do naturally (even from
youth). Realize that no one is going to give up any great ideas
(occasionally a GPLer may have a light bulb on though): the industry
doesn't work that way. You'd have to base the economy differently for
that kind of thing to work to a high degree. Mostly, you'll see the
scientists/academics publish like they always have at a level perhaps
removed from comprehension (read, it's always complex). Ever wonder why
VBXs never took off?
> This turns out to be much harder than it seems. I work in testing
> and have adapted patterns to express test design strategies. I have
> written about two dozen test design patterns. Although I'd previously
> written detailed explanations with examples of many different test
> strategies, recasting them as patterns sharpened my focus and
> generally improved the whole thing. I think it also better serves
> the reader by providing the same handles on different concepts.
Again, that's fine if you're into giving away your inventions instead of
keeping them a secret and making money from them.
> What I also confirmed is that patterns aren't the best way to
> express many subjects -- developing and explaining a conceptual
> framework, telling a story (what happened), explaining how
> a particular technical works, or presenting the theory that supports
> an approach.
Right, they're just a teeny-tiny tool in the toolbox applied as
appropriate when you want to share your ideas. But really any way of
documenting a "design" is the same thing. Promoting a new term at every
turn is bad practice. I certainly wouldn't have given them the OK to
coin a new term in the "patterns" case.
Finally, too much _definition_ can mean _limitation_ as it promotes
"inside the box" thinking. (The old "mechanism" vs. "policy"
discussion?)
Tony
Jeff Younker
> > What I also confirmed is that patterns aren't the best way to
> > express many subjects -- developing and explaining a conceptual
> > framework, telling a story (what happened), explaining how
> > a particular technical works, or presenting the theory that supports
> > an approach.
>
> Right, they're just a teeny-tiny tool in the toolbox applied as
> appropriate when you want to share your ideas. But really any way of
> documenting a "design" is the same thing. Promoting a new term at every
> turn is bad practice. I certainly wouldn't have given them the OK to
> coin a new term in the "patterns" case.
My understanding is that the idea of 'patterns' was not developeed
for software, but for architecture, and the term was coined to describe
patterns in building design, not software design. The software commuity
just happens to be the place where the concept has taken root most
deeply.
Does anybody happen to know this person's name or have references
tp his or her publications, or am I just having memories of things
that never happened?
- Jeff Younker - je...@mdli.com - These are my opinions, not MDL's -
Robert C. Martin
Jeff Younker wrote in message ...
>
>My understanding is that the idea of 'patterns' was not developeed
>for software, but for architecture, and the term was coined to describe
>patterns in building design, not software design. The software commuity
>just happens to be the place where the concept has taken root most
>deeply.
>
>Does anybody happen to know this person's name or have references
>tp his or her publications, or am I just having memories of things
>that never happened?
You are quite correct. The architect is a fellow named Christopher
Alexander. He wrote two critical books that described the notion of
patterns. The first is called "The Timeless Way of Building", and the
second is called "A Pattern Language". The first book is very fluffy and
etherial, but in its more lucid moments it manages to describe the notion of
design patterns and how they might be used in architecture. The second book
is much more concrete and describes many patterns discovered by Alexander.
Software patterns did not start from this seed. Erich Gamma started his
doctoral thesis before he had ever heard of Alexander. That thesis was the
progenitor of the GOF book (Design Patterns, Addison Wesley, 1995).
I don't remember the precise history, but one of the other three authors of
the book introduced Alexander's concept to Gamma, and the term "Design
Patterns" was born into the software industry.
There are some significant differences between software design patterns as
published in the GOF book, and Alexander's patterns of architecture.
Alexander's patterns were patterns of artistry, of aesthetics, of beauty.
They were aimed more at the intangible side of architecture than the
functional side. Gamma's pattern, on the other hand are pragmatic useful
techniques that solve real problems faced by engineers almost daily. Rather
than being aesthetic in nature (although some find them beautiful anyway)
they are functional in nature. Rather than focussing upon the intangible,
they tangibly address core issues and problems.
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
Bob Binder
Jeff Younker wrote in message ...
>
>tp his or her publications, or am I just having memories of things
>that never happened?
Jeff
Brad Appleton has put together a very nice introduction to patterns
which covers some of the antecedents.
Patterns in a Nutshell,
http://www.enteract.com/~bradapp/docs/patterns-nutshell.html
The notion was originally articulated by Christopher Alexander,
an Architectural theorist, for the design of buildings and towns.
Tom DeMarco made the first application of Alexander's ideas
to software engineering, in the late 1970s. Alexander was
subsequently re-discovered in the early 1990s by OO developers
including Kent Beck, Ward Cunningham, and Ralph Johnson.
John D Salt
>>for software, but for architecture, and the term was coined to describe
>You are quite correct. The architect is a fellow named Christopher
>Alexander. He wrote two critical books that described the notion of
>patterns. The first is called "The Timeless Way of Building", and the
I wonder whether the contributors to this group consider patterns as
implemented in Beta to be patterns in this sense?
If not, why not?
All the best,
John.
[Who wonders if we're in for another game of "Ignore the Norwegian" ;-)]
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.
Patrick Logan
: I wonder whether the contributors to this group consider patterns as
: implemented in Beta to be patterns in this sense?
: If not, why not?
Maybe you could give us an overview of patterns as implemented in
Beta. Are they like pattern matching in other languages like Haskell,
SML, and Erlang?
: [Who wonders if we're in for another game of "Ignore the Norwegian" ;-)]
Who's ignoring the Norwegian. Haven't they had a lot of influence on
language design? Even Beta apparently has influenced the design of
Java's inner classes. Although I think I'd probably rather try the
Real Thing.
--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com
Robert C. Martin
Bob Binder wrote in message <6vamii$bcf$1...@Nntp1.mcs.net>...
>
>Tom DeMarco made the first application of Alexander's ideas
>to software engineering, in the late 1970s.
Hay Bob! That's *interesting*. Do you have a reference?
Tony
> The notion was originally articulated by Christopher Alexander,
> an Architectural theorist, for the design of buildings and towns.
>
> subsequently re-discovered in the early 1990s by OO developers
> including Kent Beck, Ward Cunningham, and Ralph Johnson.
It's simply amazing how much mileage people have gotten on a fundamental
way of thinking!
Tony
Brad Appleton
"Bob Binder" <rbi...@rbsc.mapson.com> writes:
>Brad Appleton has put together a very nice introduction to patterns
>which covers some of the antecedents.
>
>Patterns in a Nutshell,
>http://www.enteract.com/~bradapp/docs/patterns-nutshell.html
Thanks for the honorable mention. Those wanting a more thorough
(and lengthy) intro can see:
http://www.enteract.com/~bradapp/docs/patterns-intro.html
>Tom DeMarco made the first application of Alexander's ideas
>to software engineering, in the late 1970s.
Hmmn - do you mean Tom DeMarco, or Tom Gilb? I know DeMarco & Lister
refer to much of Alexander's stuff in their famous "PeopleWare" book,
but they are referring to ergonomics and human factors in the design of
the workspace/workplace for software developers.
Tom Gilb on the other hand refers to Alexanders work in the context of
software development in his class "Principle of Software Engineering
Management". Is that what you meant?
> Alexander was
>subsequently re-discovered in the early 1990s by OO developers
>including Kent Beck, Ward Cunningham, and Ralph Johnson.
Actually, Beck & Cunningham's "rediscovery" was in the late 80s
(circa 1987).
Cheers!
--
Brad Appleton <bra...@enteract.com> | http://www.enteract.com/~bradapp/
"And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng
Ralph Johnson
>There are some significant differences between software design patterns as
>published in the GOF book, and Alexander's patterns of architecture.
>Alexander's patterns were patterns of artistry, of aesthetics, of beauty.
>They were aimed more at the intangible side of architecture than the
>functional side. Gamma's pattern, on the other hand are pragmatic useful
>techniques that solve real problems faced by engineers almost daily. Rather
>than being aesthetic in nature (although some find them beautiful anyway)
>they are functional in nature. Rather than focussing upon the intangible,
>they tangibly address core issues and problems.
You are not being fair to Alexander. Sure, he is much more motivated
by esthetics than most software people. But the patterns are not about
artistry and beauty. They are about entrances, parking, bedrooms,
windows, and other functional aspects of buildings. They solve problems
of privacy, communication, being able to see things, and safety. In
addition, they (are supposed to) produce beautiful buildings.
Alexander believes that beauty is not distinct from functionality.
The most functional things will be beautiful. Also, he is interested
in a kind of beauty that quite different from museum art. He is
interested in things that fit together just right, that are right
where you need them, that make you happy. In general, software
developers are not opposed to these things, we just set lower goals
for ourselves, being ecstatic if we just bring the project in on
time and under budget, with reasonably happy customers. I think we
will eventually worry about the same kind of things that Alexander did.
-Ralph Johnson
Bob Binder
Brad Appleton wrote in message <6vbktv$a7...@nntp.cig.mot.com>...
>In article <6vamii$bcf$1...@Nntp1.mcs.net>,
> "Bob Binder" <rbi...@rbsc.mapson.com> writes:
>>Brad Appleton has put together a very nice introduction to patterns
>>which covers some of the antecedents.
>>
>>Patterns in a Nutshell,
>>http://www.enteract.com/~bradapp/docs/patterns-nutshell.html
>
>Thanks for the honorable mention. Those wanting a more thorough
>(and lengthy) intro can see:
>
>http://www.enteract.com/~bradapp/docs/patterns-intro.html
>
>>Tom DeMarco made the first application of Alexander's ideas
>>to software engineering, in the late 1970s.
>
>Hmmn - do you mean Tom DeMarco, or Tom Gilb? I know DeMarco & Lister
>refer to much of Alexander's stuff in their famous "PeopleWare" book,
>but they are referring to ergonomics and human factors in the design of
>the workspace/workplace for software developers.
Tom DeMarco. Alexander's first major publication was
_Notes on the Synthesis of Form_ (Cambridge: Harvard University
Press, 1964.)
This lays the foundation (very abstractly) for identifying
patterns and establishes a design tool now commonly used by architects:
the bubble chart, showing the usage relationship of one space
to another. This is actually quantified in an interesting
application of Shannon information theory. DeMarco used this notion
in support of his data flow modeling approach, which, among other
things, relies on the simple but effective heuristic of
minimizing interface complexity.
See Tom DeMarco, _Structured Analysis and System Specification_
(Englewood Cliffs: Prentice-Hall Inc., 1978.)
Alexander's model noted that like water shaping a river, usage
tends towards stable, similar patterns over time. He
suggested the design process could leverage this effect by
looking for and designing to usage patterns *before*
constructing a building. Alexander spent the next 20 years looking
for such patterns and cataloged his findings in his two pattern books.
DeMarco followed Alexander's subsequent work, and used some of
the human factors aspects of space patterns in the various
arguments advanced in _Peopleware_.
>
>Tom Gilb on the other hand refers to Alexanders work in the context of
>software development in his class "Principle of Software Engineering
>Management". Is that what you meant?
>
No.
Bob Binder
Robert C. Martin wrote in message <6vas2p$21c$1...@hirame.wwa.com>...
>>to software engineering, in the late 1970s.
>
>
>
See my reply to Brad Appleton.
John D Salt
Patrick Logan <plo...@user1.teleport.com> wrote:
>In comp.object John D Salt <css...@brunel.ac.uk> wrote:
>
>: I wonder whether the contributors to this group consider patterns as
>: implemented in Beta to be patterns in this sense?
>
>: If not, why not?
>
>Maybe you could give us an overview of patterns as implemented in
>Beta. Are they like pattern matching in other languages like Haskell,
>SML, and Erlang?
While I've no experience of any of these three, the term "pattern
matching" seems to me to indicate that this isn't the same kind
of thing as patterns in Beta.
The Beta Terminolgy intro available at
http://www.daimi.aau.dk/~beta/
gives an idea, although it is not immediately obvious that this
usage is any more than a slight extension of the idea of a class.
One of these fine days, I've promised myself I shall learn more
about Beta, which has the twin virtues of being another invention
(at least partly) by Kristen Nygaard, and of being free -- check
out http://www.mjolner.dk/ ... no, I don't have shares in them,
honest! ;)
>
>: [Who wonders if we're in for another game of "Ignore the Norwegian" ;-)]
>
>Who's ignoring the Norwegian. Haven't they had a lot of influence on
>language design? Even Beta apparently has influenced the design of
>Java's inner classes.
What, they managed to ignore Simula's inner classes for that
long, did they?
All the best,
John.
Patrick Logan
: You are not being fair to Alexander. Sure, he is much more motivated
: by esthetics than most software people. But the patterns are not about
: artistry and beauty. They are about entrances, parking, bedrooms,
: windows, and other functional aspects of buildings. They solve problems
: of privacy, communication, being able to see things, and safety. In
: addition, they (are supposed to) produce beautiful buildings.
The thing I like most about Alexander's writing is that he *is*
focussed on things that work, traditions that have survived, evolved,
and have been repeated.
I think there is more room(!) for "beauty" in architecture than in
software in the sense that there are more ways to express beauty in
architecture than in software. So while we need to find new
understandings of "beautiful software" (mostly in its "exterior" human
interfaces), I think architecture and especially software can benefit
from less intangible measurements like "Quality Without A Name" and
more tangible measurements of *why* some architecture and some
software works better than others.
Alexander appeals to my emotions, but after a romantic journey with
him, he left me wanting more.
--
John Goodsen
Albert Ratzlaff wrote in message <36163135...@infonet.com.py>...
>
>
>Tony wrote:
>
>> > >Richard J Kucera wrote:
>> > >IMHO, the whole
>> > >pattern movement, even in its infancy, has improved the quality of
>> > >software.
>>
>> Realize that "patterns" is just a fad term for a concept/way-of-thinking
>> as old as mankind and nothing new at all. Caveman ties a stone on a
>> stick and calls it the "hammer" pattern. Patterns are nothing more than
>> designs and inventions that may have broader applicability, don't get too
>> bogged down in it. If you've ever built anything from scratch before at
>> all, you've probably used patterns and many more than the few that have
>> been popularly written about in computer texts. If you see a design
>> that's useful to you, then use it and/or catalog it in your brain or
>> elsewhere.
>>
>> When in doubt, go back to first principles. There's not as much "new"
>> technology as the industry would have you believe. There is plenty of
>> marketing hype though so beware of the trend that attempts to coin
>> common sense for profit.
>>
>> Tony
>
>Right. For example, story writers and movie people have used patterns for
>ages. Never heard about the "Boy meets girl, boy falls in love with girl,
>etc.etc." pattern? I've heard it said that there are only a few basic
>patterns for story arguments. You know the pattern, you know how it ends.
>
Patterns may or may jot be a "fad term", but the examples above
are not patterns. One cannot just post a paragraph on comp.object
and declare that they have explained the "hammer" pattern, for
example. What is the problem being solved? What are the forces?
Sometimes a problem has a different solution, depending upon the
forces. Patterns give us guidance WITHIN A CONTEXT !. Sure, the
solutions seem straightforward after the fact, but somebody has taken
great pains to make their pattern read well enough to compell you to
use the pattern as a solution.
Using the hammer analogy above, how many times have you heard
somebody say "If all you have is a hammer, then everything looks like
a nail". What is lacking in the post above is any discussion on the
Hammer *PATTERN*, if one exists. Merely stating that a caveman
ties a stone to a stick is some type of pattern does not make it so.
So the point I'm trying to make is that patterns are the result of a lot
of thought and in good patterns, great pains are taken to describe
exactly what solution can be solved under what forces with the pattern.
If all we had was a small toolbox of a few screwdrivers, a hammer
and a few wrenches (to use the same analagy) - then clearly, we
don't need a pattern language to help us use these tools more
effectively. But this is software design. There are already hundreds
of software design patterns that have been well described. We cannot
keep these all in our head, at the ready for every project we tackle.
The formal nature of writing down and cataloging patterns will become
more and more important for us, as an industry, to facilitate the rapid
adoption of entry-level developers into our profession as well as the
maintenance of our own skill sets.
--
John Goodsen RADSoft / Training, Mentoring and Consulting in:
jgoo...@radsoft.com - UML modeling and OOA/D principles
http://www.radsoft.com - Use Centered Object-Oriented Design
602.283.0142 - Rapid Incremental S/W Delivery Process
"Example isn't another way to teach, it is the only way to teach. "
- Albert Einstein
Tony
jgoo...@radsoft.com says...
Contraire! It doesn't take a rocket scientist to realize the usefulness
of the pounding device in many circumstances (contexts). One might even
say that it is a "default" pattern at a very high level of abstraction!
;) (when all else fails, give it a whack).
> There are already hundreds
> of software design patterns that have been well described.
But only the common, well known ones and in someone else's "icky" naming
convention. I wouldn't look for any innovative breakthroughs there
because largely the marketable inventions stay locked up by the inventing
companies. Even academia realizes this it would seem: BDB was a good
start for database implementation, but the full featured version became a
licensed proposition.
> We cannot
> keep these all in our head, at the ready for every project we tackle.
> The formal nature of writing down and cataloging patterns will become
> more and more important for us, as an industry, to facilitate the rapid
> adoption of entry-level developers into our profession as well as the
> maintenance of our own skill sets.
See above comment. I don't believe "the industry" will do this. And
independent companies (with large, valuable designs) _have_been_ doing
this in some form since they began. One can consider these practices a
sub category of "knowledge management" or "asset management" or even
"reuseability" etc. Again, back to basics.
One more thought: since the trend is to move away from source code
reuseability and on to component reuseability, "patterns" may be a day
late and a dollar short. (Internally, a software company should be
practicing knowledge and asset management though).
Tony
Biju Thomas
>
> In article <ELtS1.13690$Dj1.7...@news.rdc1.az.home.com>,
> jgoo...@radsoft.com says...
> > keep these all in our head, at the ready for every project we tackle.
> > The formal nature of writing down and cataloging patterns will become
> > more and more important for us, as an industry, to facilitate the rapid
> > adoption of entry-level developers into our profession as well as the
> > maintenance of our own skill sets.
>
> independent companies (with large, valuable designs) _have_been_ doing
> this in some form since they began.
May be large companies have been documenting and distributing design
techniques among their own people. But what the pattern movement (I
could not find a better term for it) is doing is popularizing valuable
and commonly used design methods, so that everyone doesn't have to
reinvent the wheel. This knowledge dissemination may be against the
interests of some corporations, but it is in the interest of whole
society to do so.
About they inventing new terms for describing these techniques - it is
easier to communicate with others if all agree on some basic
terminology. We would not ask mathematicians to avoid using terms like
ring, group etc. Software community is also entitled to such rights.
> One more thought: since the trend is to move away from source code
> reuseability and on to component reuseability, "patterns" may be a day
> late and a dollar short. (Internally, a software company should be
> practicing knowledge and asset management though).
In fact, many of the patterns are about reusing such components to
design better systems. So, I don't see how component reusability and
patterns conflict with each other. OTOH, component reusability and
algorithms have some conflict of interest, since many algorithms will be
embedded in components, and everyone doesn't have to know such inner
details.
Regards,
Biju Thomas
Patrick Doyle
Tony <To...@ask.me> wrote:
>
>Realize that "patterns" is just a fad term for a concept/way-of-thinking
>as old as mankind and nothing new at all.
Give it a rest, man. Sure, patterns are nothing new. That's
the whole point. But it doesn't mean they're not helpful
or worth studying.
You're not doing anyone any favours by belittling every piece
of terminology anyone mentions in this newsgroup.
-PD
--
--
Patrick Doyle
doy...@ecf.toronto.edu
Dave Whipp
> > There are already hundreds
> > of software design patterns that have been well described.
>
> But only the common, well known ones and in someone else's "icky" naming
Isn't that the whole idea of patterns - that they aren't innovative
breakthroughs. To call something a pattern it must first have been used
enough to demonstrate what forces effect it and what its consequences
are.
Consolidation of existing knowledge is at least as important as
important as innovation in any discipline that wants to mature.
Dave.
--
Dave Whipp, Siemens AG: HL DC PE MC, MchM, Munich, Germany
mailto:David...@hl.Siemens.de Phone. +49 89 636 83743
Opinions are my own. Factual statements may be incorrect.
Robert C. Martin
Tony wrote in message ...
>
>reuseability and on to component reuseability, "patterns" may be a day
>late and a dollar short
Component reusability is non-trivial. Making sure that the dependencies
between components are well managed is something that certain patterns are
quite useful for; and no doubt other patterns will be discovered for. Thus,
I doubt that the "day late, dollar short" supposition is valid.
Robert C. Martin
Dave Whipp wrote in message <361B60A0...@hl.siemens.de>...
>Tony wrote:
>> > There are already hundreds
>> > of software design patterns that have been well described.
>>
>> But only the common, well known ones and in someone else's "icky" naming
>> convention. I wouldn't look for any innovative breakthroughs there [...]
>
>Isn't that the whole idea of patterns - that they aren't innovative
>breakthroughs. To call something a pattern it must first have been used
>enough to demonstrate what forces effect it and what its consequences
>are.
Right. The motto is: "There's nothing new here." The patterns themselves
are tried and true techniques that have been working in many different
contexts for a long time.
On the other hand, the idea of writing these tried and true techniques down
in a problem/context/solution format, and giving them names, is rather new
in the software industry. The innovation is not in any of the patterns
themselves, but in the way that they are presented.
Tom Valesky
Getting back to the original subject of this thread, I'd like to see
some discussion of the merits of "anti-patterns" (an "anti-pattern" being
a pattern that is known to generate an unsatisfactory outcome).
Do you think that the study and cataloging of anti-patterns is worthwhile?
My opinion: I think that the software industry has had quite a few spectacular
failures, and that it is a worthwhile endeavor to study these failures
and attempt to codify the steps that were taken in the project to lead
to the failure. Perhaps if we can enumerate the things that lead
to failure, we can avoid doing them, and in so doing increase our
chances of success.
--
===========================================================================
Tom Valesky -- tval...@patriot.net
http://www.patriot.net/users/tvalesky
Patrick Doyle
Tony <To...@ask.me> wrote:
>
>One more thought: since the trend is to move away from source code
>reuseability and on to component reuseability, "patterns" may be a day
Patterns are not about source code reuse. In fact, if source code reuse
is possible, design patterns are not necessary.
This further illustrates that you should have some idea what you are
talking about before you criticize it.
Tony
> May be large companies have been documenting and distributing design
> techniques among their own people. But what the pattern movement (I
> could not find a better term for it) is doing is popularizing valuable
> and commonly used design methods, so that everyone doesn't have to
> reinvent the wheel. This knowledge dissemination may be against the
> interests of some corporations, but it is in the interest of whole
> society to do so.
This is the GPL spiel. Most people fall into one category or the other:
they accept that the system of business creation meets the product and
service needs of society OR they seek a more "communal, non-monetary"
alternative (GPL e.g.). Most of the leaders choose to start their own
companies. The other side organizes the basics and sometimes the
obsolete for the traininf of the "up and comers". Point: only the
fundamentals make it into the "free" products. You get what you pay for.
> About they inventing new terms for describing these techniques - it is
> easier to communicate with others if all agree on some basic
> terminology.
Yep, but better still if you can use EXISTING terminology.
> We would not ask mathematicians to avoid using terms like
> ring, group etc. Software community is also entitled to such rights.
Invention of new terminology needs to be the exception rather than the
rule. Don't pollute the namespace. :)
> > One more thought: since the trend is to move away from source code
> > reuseability and on to component reuseability, "patterns" may be a day
> > late and a dollar short. (Internally, a software company should be
> > practicing knowledge and asset management though).
>
> In fact, many of the patterns are about reusing such components to
> design better systems. So, I don't see how component reusability and
> patterns conflict with each other. OTOH, component reusability and
> algorithms have some conflict of interest, since many algorithms will be
> embedded in components, and everyone doesn't have to know such inner
> details.
Most "patterns" describe a high level _implementation_ design. Intra-
company this is useful. Inter-company reuse is better done via
components.
Tony
Tony
Just making the case that the invention of new terminology should be the
exception rather than the rule. Most of it needs to have a "tm"
superscripted to it I think.
Tony
Tony
says...
> Tony wrote:
> > > There are already hundreds
> > > of software design patterns that have been well described.
> >
> > But only the common, well known ones and in someone else's "icky" naming
> > convention. I wouldn't look for any innovative breakthroughs there [...]
>
> Isn't that the whole idea of patterns - that they aren't innovative
> breakthroughs. To call something a pattern it must first have been used
> enough to demonstrate what forces effect it and what its consequences
> are.
>
> important as innovation in any discipline that wants to mature.
It's a good idea to document but I think successful "repositories" will
be at the interface rather than the implementation level. i.e. Software
Component catalogs. Each software company will continue to manage their
engineering uniquely.
The popular design books (GOF etc) are good basic training and
recommended reading, they're not the basis of a software engineering
organization however. They may make up for the lack of such design
training in curriculums?
Tony
Tony
> >> > There are already hundreds
> >> > of software design patterns that have been well described.
> >>
> >> But only the common, well known ones and in someone else's "icky" naming
> >> convention. I wouldn't look for any innovative breakthroughs there [...]
> >
> >Isn't that the whole idea of patterns - that they aren't innovative
> >breakthroughs. To call something a pattern it must first have been used
> >enough to demonstrate what forces effect it and what its consequences
> >are.
>
>
> are tried and true techniques that have been working in many different
> contexts for a long time.
>
> On the other hand, the idea of writing these tried and true techniques down
> in a problem/context/solution format, and giving them names, is rather new
> in the software industry.
Nah, maybe in rather unsophisticated companies it is. When things scale
up (more people need to know, the quantity of information is large...),
this kind of documenting, cataloging is traditional engineering
management practice.
On a more industry perspective, pick up just about any software book and
you'll find many designs that apply to the subject of the book, you just
have to be able to recognize them. Mostly though, they serve to
stimulate thinking rather than provide a recipe for direct reuse because
most contexts for implementation are not alike.
If one perceives the current trendy materials as only another sliver
source of information for systems building, then OK. (Ah! Back to
definitions vs. abstractions again. :) )
Tony
Tony
>
> Tony wrote in message ...
> >
> >reuseability and on to component reuseability, "patterns" may be a day
>
> Component reusability is non-trivial. Making sure that the dependencies
> between components are well managed is something that certain patterns are
> quite useful for; and no doubt other patterns will be discovered for. Thus,
> I doubt that the "day late, dollar short" supposition is valid.
Good point: that the infrastructure for a component industry is not yet
well defined. But I don't believe that design internals will be the
primary (or even the usual rather than exceptional) selection criteria
for components (else we wouldn't have gained anything!).
The "day late, dollar short" referred to "patterns" being in an older
(not de jure) part of the process evolution of software development.
Tony
Tony
> >reuseability and on to component reuseability, "patterns" may be a day
>
> Patterns are not about source code reuse. In fact, if source code reuse
> is possible, design patterns are not necessary.
Well try to use some intuition (hah!) and extrapolate a little. "Design
reuse" then. Still not the goal. Get it now Mr. Doyle?
> This further illustrates that you should have some idea what you are
> talking about before you criticize it.
I think you just stepped in some. Go wipe your shoes off now. LOL!
Tony
Steven Perryman
>Getting back to the original subject of this thread, I'd like to see
>some discussion of the merits of "anti-patterns" (an "anti-pattern" being
>a pattern that is known to generate an unsatisfactory outcome).
>Do you think that the study and cataloging of anti-patterns is worthwhile?
IMHO, yes.
It's good to learn by your mistakes, but better still to learn from mistakes
made by others. Just as many of us used patterns without naming them in their
'canonical' forms, so many of us have probably seen many of the anti-patterns
in effect on projects (again without a succinct name for them) .
>My opinion: I think that the software industry has had quite a few spectacular
>failures, and that it is a worthwhile endeavor to study these failures
>and attempt to codify the steps that were taken in the project to lead
>to the failure. Perhaps if we can enumerate the things that lead
>to failure, we can avoid doing them, and in so doing increase our
>chances of success.
One of the dangers for me is that some of the anti-patterns deal with people
behaviour. Highlighting the presence of these ones can be perilous indeed.
It would be nice if the industry would have regular 'project disaster - why
we failed' conferences. So much goes on (methods, prog langs, technologies
etc) where people step up and proclaim "We did/used so and so, and it was a
great success !!! We saved this/improved that blah blah ..." ) . Yet the
failures, which we are lead to believe are numerous, are only ever spoken as
anecdotes, in hushed tones and in dark corridors. :-)
Regards,
Steven Perryman
ste...@nortel.co.uk
Oren Ben-Kiki
Tom Valesky wrote in message ...
>
>Getting back to the original subject of this thread, I'd like to see
>some discussion of the merits of "anti-patterns" (an "anti-pattern" being
>a pattern that is known to generate an unsatisfactory outcome).
Is there really such a thing? One could make a case that almost any
solution - no matter how contrived - is a proper fit for some instance of a
problem. Admittedly the problem may be as contrived as the "anti-pettern".
>Do you think that the study and cataloging of anti-patterns is worthwhile?
It is very worthwhile excplicitly documenting for each pattern the
conditions under which it is _not_ appropriate, and why. But it only makes
sense to do so for patterns which people are likely to (mistakenly) use,
which means that such patterns do have _some_ advantage - for example, they
may be faster/simpler to design/implement/execute - in which case there may
be a reasonable problem instance in which they would be proper.
Share & Enjoy,
Oren Ben-Kiki
Skip Sailors
>...
>Do you think that the study and cataloging of anti-patterns is worthwhile?
IMHO, the study of failures is NP complete. If chemists documented
all the ways that they accidently produced useless green goo, rather
than concentrating on the one or two ways to make Teflon, there would
be no trees left.
OTOH, there are some commonly repeated patterns of behvior that should
be avoided. So I think the study of anti-patterns is useful, but the
cataloging of them would be futile.
Tim Ottinger
>
> Tony wrote in message ...
> >
> >reuseability and on to component reuseability, "patterns" may be a day
>
> Component reusability is non-trivial. Making sure that the dependencies
> between components are well managed is something that certain patterns are
> quite useful for; and no doubt other patterns will be discovered for. Thus,
> I doubt that the "day late, dollar short" supposition is valid.
I agree with Robert that patterns are useful for consolidating any industry
knowledge, not necessarily how to use source code. They're really design
tools, not code management tools anyway (though sometimes the two are
inseparable). Organization patterns, SPI patterns, SCM patterns, etc are
completely unaffected by changes in how source code or binaries are shared.
We'll come up with patterns for whatever we do, as long as we can follow
the Rule of Three and have enough exposure to recognize real trends.
But the day late part has a core truth in it. Patterns document what has
been done, so that they can only document the past (recent or distant,
no matter). Looking for "new" stuff in patterns is like trying to buy a
chicken from a car dealership.
But that doesn't mean that the patterns are outmoded, either. A lot of
them apply as well to interfaces in COM as interfaces in Java as pure
virtual interfaces in C++, etc.
Also, what's old news to one person is as fresh as tomorrow to the
next. I've read patterns from "foriegn" fields of software and been
surprized and inspired.
Best of all, good patterns are really timeless. We will be dealing
in separation of concerns, coupling, and cohesion as long as software
exists. The forces don't go away just because we have new ways of
instantiating them.
Tim
Tim Ottinger
in the same family as reading "The Art of Computer Programming" or
"Structured Programming" or "Concurrent Java" or Tennenbaum's OS book.
If you don't feel that there is any value in learning what other
people have done successfully, that the lessons learned by others
are either old-hat to you or otherwise irrelevant then there is
no reason to learn anything, and you can go on happily.
But if you feel that you still have some things to learn, then you
read about other people's experiences and the solutions that they've
found to work. You read about the issues that made the problem hard,
and reason as to why and how that solution resolves all issues or
makes a good engineering tradeoff, and you consider when it might
be wise to follow suit -- and when it is not.
Sure patterns are nothing new. In fact, the community makes no bones
about that and no excuses. The definition of a pattern is "nothing new",
and the moral imperative for writing them is the same. The goal isn't
to do something novel, but do give good, solid, proven advice.
If someone hypes the pattern thing as being more than that, or less,
then please sedate them and call for security. It's not a miracle
drug or a new scientific breakthrough, a new science, philosophy,
or religion. It's just good technical advice in a consistent format.
Tim
Tim Ottinger
> Do you think that the study and cataloging of anti-patterns is worthwhile?
It is a good idea with opportunity for abuse.
It's nice to have someone flag all of the land mines. After all, you never
really know why a project succeeds, but it's easy to catalog the way one
has failed. If there are clear, obvious, commonsense "solutions" that
fail, then noting that and disseminating the information is a good idea.
But...
It could easily turn into a bunch of bitter people accusing all decisions
of being made by idiots, and listing all steps as being stupid and wrong.
It's easy to criticize, much easier than giving good advice. I fear this
could become a "low art", kind of the "Springer show" of engineering.
Ralph Johnson once said that there is probably a context for just about
every solution, and it might be better to write patterns instead of
antipatterns (casual conversation with a group at U of I, I didn't
note the date). The idea was to document a decision as a pattern, and
make it clear in the forces that some possible outcomes are to be avoided.
Tim
Patrick Doyle
Ok, what's the existing terminology for "design pattern"?
>Most "patterns" describe a high level _implementation_ design.
How do you know? A few days ago you claimed they involved
code reuse, thus demonstrating you didn't know what they
were. Are we to believe that you have, since then, read
"most" patterns?
>Intra-
>company this is useful. Inter-company reuse is better done via
>components.
Why is that? Just a few posts ago you told us that code reuse was
passe. Now it's the preferred way to get inter-company reuse?
Patrick Doyle
Tony <To...@ask.me> wrote:
>In article <F0GyB...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
>> In article <MPG.1084476b5...@netnews.worldnet.att.net>,
>> Tony <To...@ask.me> wrote:
>> >
>> >reuseability and on to component reuseability, "patterns" may be a day
>>
>> Patterns are not about source code reuse. In fact, if source code reuse
>> is possible, design patterns are not necessary.
>
>Well try to use some intuition (hah!) and extrapolate a little. "Design
>reuse" then. Still not the goal. Get it now Mr. Doyle?
No, I don't get it. What, am I supposed to change the words in
your posts until they make sense to me? Why don't you say what
you mean in the first place?
Now here are a few of specific questions:
1. Where have you seen this trend away from design reuse?
2. Is it beneficial to move away from design reuse toward component
reuse? Or is it just a trend you have observed?
3. If we move away from design reuse, does that mean that
design patterns become useless?
4. Do you think it's possible to express all reuse as components,
thus making design patterns obsolete?
Tony
> If someone hypes the pattern thing as being more than that, or less,
> then please sedate them and call for security. It's not a miracle
> drug or a new scientific breakthrough, a new science, philosophy,
> or religion. It's just good technical advice in a consistent format.
I'm don't think a "consistent format" has been accepted or is even
desireable. The best ones are probably just labeled boxes and arrows
(designs) with a short description. MSJ does a pretty good job, but of
course most of theirs are contrived to generate maximum revenue rather
than to be maximally elegant. A picture worth a thousand words?
Tony
Tony
> In article <MPG.1085cff1e...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
> >
> >Yep, but better still if you can use EXISTING terminology.
>
> Ok, what's the existing terminology for "design pattern"?
"Design". The concern is that the slightly new term (adding "patterns")
is an attempt to make the practice appear as something "NEW" when it's
not. It's standard engineering management practice. Don't hold your
breath waiting for everyone to replace the term "design" with "pattern"
in their vocabulary.
> >Most "patterns" describe a high level _implementation_ design.
>
> How do you know? A few days ago you claimed they involved
> code reuse, thus demonstrating you didn't know what they
> were. Are we to believe that you have, since then, read
> "most" patterns?
No, a few days ago you contrived that scenario to fit your objective
missing the whole point of my post. Go back and reread it and the follow
up.
The two popular texts have been on my shelf for over a year at least.
Certainly one of them (I forgot which) gives the impression of poorly
thought out presentation and too much of an attempt to come up with a
consistent format that makes it overly verbose if not repetitive. (Not
to say that the _information_ contained within is not useful, just that
it's organization was poor (opinion)).
> >Intra-
> >company this is useful. Inter-company reuse is better done via
> >components.
>
> Why is that? Just a few posts ago you told us that code reuse was
> passe. Now it's the preferred way to get inter-company reuse?
My, my .. isn't someone out for blood now. Reread the statement. It
says: Intra-company reuse ok at source code level; Inter-company reuse ok
at component level. Perhaps you don't know "intra-" vs. "inter-"?
Go easy on the caffeine. ;)
Tony
Tony
> In article <MPG.1085dad95...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
> >In article <F0GyB...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
> >> In article <MPG.1084476b5...@netnews.worldnet.att.net>,
> >> Tony <To...@ask.me> wrote:
> >> >
> >> >One more thought: since the trend is to move away from source code
> >> >reuseability and on to component reuseability, "patterns" may be a day
> >> >late and a dollar short.
> >>
> >> Patterns are not about source code reuse. In fact, if source code reuse
> >> is possible, design patterns are not necessary.
> >
> >Well try to use some intuition (hah!) and extrapolate a little. "Design
> >reuse" then. Still not the goal. Get it now Mr. Doyle?
>
> No, I don't get it.
Source reuse is a "micro-" process that has proven to be too unwieldly to
be practical as the primary level of reuse management. (It pushes
certain management responsibility to the programmer level where it's not
necessarily desireable). Design level reuse is only incrementally better
and still to low level. Component level reuse seems to have the correct
attributes and potentials (I'll leave that dialog as an excercise for the
reader). Clear as mud yet?
Tony
Tony
> 2. Is it beneficial to move away from design reuse toward component
> reuse? Or is it just a trend you have observed?
> 3. If we move away from design reuse, does that mean that
> design patterns become useless?
> 4. Do you think it's possible to express all reuse as components,
> thus making design patterns obsolete?
Programmers and designers will continue to reuse at the micro level (it's
their job!). It's not either/or but rather "applied at the appropriate
level". Design/source reuse is basically PROGRAMMING. I'll bet someone
here can relate the two (source reuse, component reuse) to CMM level.
Tony
- Is SEI CMM just a hoax of terminology? Hasn't it all been
defined before? Just kidding guys!!! :)
Greg Gibson
>
> "Design". The concern is that the slightly new term (adding "patterns")
> is an attempt to make the practice appear as something "NEW" when it's
> not.
Not quite. Even though it seems strange, I always think of sewing
patterns as analogous to design patterns.
A sewing pattern is not a garment, it is a guide to how to make many
variants of a garment. One hundred different people can use the
same pattern and make one hundred different garments, each useful
in the same way.
So, deciding how to lay out your specific garment is the counterpart
to design. This is different than the sewing pattern you use to lay
out the garment, which is the counterpart to the design pattern.
--
Greg P. Gibson Inet: gib...@agcs.com, http://www.agcs.com
AG Communication Systems Talk: 602-582-7524 Fax: 602-582-7697
Phoenix, AZ 85072-2179 "Expand the power of your network"
Patrick Doyle
Tony <To...@ask.me> wrote:
>In article <F0JBC...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
>>
>> Ok, what's the existing terminology for "design pattern"?
>"Design". The concern is that the slightly new term (adding "patterns")
>is an attempt to make the practice appear as something "NEW" when it's
>not. It's standard engineering management practice. Don't hold your
>breath waiting for everyone to replace the term "design" with "pattern"
>in their vocabulary.
"Design" and "design pattern" are two different things. A design
is a abstract view of a proposed implementation of a system. A
design pattern is a commonly-used idiom found in different designs
which share some common properties.
>> >Most "patterns" describe a high level _implementation_ design.
>>
>> How do you know? A few days ago you claimed they involved
>> code reuse, thus demonstrating you didn't know what they
>> were. Are we to believe that you have, since then, read
>> "most" patterns?
>
>No, a few days ago you contrived that scenario to fit your objective
>missing the whole point of my post. Go back and reread it and the follow
>up.
Fair enough. Still, your claim to make a judgement on "most
patterns" is still questionable, unless you claim to be familiar
with most patterns.
>The two popular texts have been on my shelf for over a year at least.
>Certainly one of them (I forgot which) gives the impression of poorly
>thought out presentation and too much of an attempt to come up with a
>consistent format that makes it overly verbose if not repetitive. (Not
>to say that the _information_ contained within is not useful, just that
>it's organization was poor (opinion)).
Interesting, but what's the relevance? Does this demonstrate that
design patterns are concerned with implementation design? Or
even if they are, does this demonstrate that this is not a good
thing?
>> >Intra-
>> >company this is useful. Inter-company reuse is better done via
>> >components.
>>
>> Why is that? Just a few posts ago you told us that code reuse was
>> passe. Now it's the preferred way to get inter-company reuse?
>
>My, my .. isn't someone out for blood now. Reread the statement. It
>says: Intra-company reuse ok at source code level; Inter-company reuse ok
>at component level. Perhaps you don't know "intra-" vs. "inter-"?
Actually, the "this" in "this is useful" was (unless I'm mistaken)
referring to the implementation design you referred to in your
previous paragraph. Also, it seems (correct me if I'm wrong) that
by "components" you mean compiled binaries, and I didn't read that
into it. So your statement, to me, read "intra-company,
implementation design reuse is useful. Inter-company reuse is
better done via code reuse". You see how I came to the conclusion
I did?
Anyway, if you're now saying that source code reuse is good within
a company while between companies, binary reuse is better, that still
seems nonsensical to me. Could you explain why this is?
And, what does all this have to do with design patterns? They
are concerned neither with code reuse nor with binary reuse.
>Go easy on the caffeine. ;)
:-)
Patrick Doyle
Tony <To...@ask.me> wrote:
>
>Source reuse is a "micro-" process that has proven to be too unwieldly to
>be practical as the primary level of reuse management. (It pushes
>certain management responsibility to the programmer level where it's not
>necessarily desireable). Design level reuse is only incrementally better
>and still to low level. Component level reuse seems to have the correct
>attributes and potentials (I'll leave that dialog as an excercise for the
>reader). Clear as mud yet?
I think I get it. You consider component reuse to be at a higher level
of abstraction from design reuse? Now *that* is the part I don't get.
Michael J. Tobler
> In article <MPG.10884a211...@netnews.worldnet.att.net>,
[snip]
> I think I get it. You consider component reuse to be at a higher level
> of abstraction from design reuse? Now *that* is the part I don't get.
> :-)
While we're on the subject of what's highly reusable, how about patterns??
They have a much higher level of reuse than components.
--
<<<<<<<<<< Blue Skies >>>>>>>>>>>
< Michael J. Tobler >
< mto...@no-spam-ibm.net >
< remove "no-spam-" when replying >
<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>
Michael J. Tobler
plo...@user1.teleport.com says...
> : While we're on the subject of what's highly reusable, how about patterns??
>
> give you some advice on how to make your own objects that meet your
> needs? Ideally, you would choose objects over advice. But because that
> is not always practical (there may not be any objects available that
> meet your needs), the next best thing is advice.
>
> That's what patterns are: advice, the next best thing to objects.
Great suggestion. Since our consulting practice never builds the same
thing twice and doing projects in different industry, I find better reuse
with analysis/design patterns and pattern languages. I find myself
architecting systems quicker this way.
As far as classes go, the only real reuse we can realize are foundation-
oriented classes - those that can be used across business and
architecture.
PS, Patrick - I know I'm being picky, but when you say "...give you some
objects...", you are speaking of classes correct? Or are you gonna ship me
some REAL objects across the wire? :)
Patrick Logan
: While we're on the subject of what's highly reusable, how about patterns??
: They have a much higher level of reuse than components.
But would you rather I give you some objects that meet your needs or
give you some advice on how to make your own objects that meet your
needs? Ideally, you would choose objects over advice. But because that
is not always practical (there may not be any objects available that
meet your needs), the next best thing is advice.
That's what patterns are: advice, the next best thing to objects.
--
Patrick Logan (H) mailto:plo...@teleport.com
(W) mailto:patr...@gemstone.com
http://www.gemstone.com
Brad Appleton
To...@ask.me (Tony) writes:
> I'm don't think a "consistent format" has been accepted ...
Actually, there are 2-3 of them that have been commonly accepted.
Perhaps you meant to say no single consistent format has been accepted.
> "Design". The concern is that the slightly new term (adding "patterns")
> is an attempt to make the practice appear as something "NEW" when it's
> not.
But the term "patterns" isn't at all new. It was a 20+ year old term
borrowed from another field and applied to software. The application
in this domain was new, the name and concept were anything but.
More importantly, one of the single most fundamental purposes of "doing
patterns" has *always* been to focus on existing "best practices" which
successfully recur. Something that is "brand new" is the antithesis of
what a pattern is, because if its new, its not a recurring phenomenon
(much less a tried and true practice that has been proven in the
trenches) and hence can't possibly be called a "pattern" in any
legitimate sense of the word.
Patterns were never an attempt to repackage old wine in new skins and
declare the result be to something "brand new" and hereto unforeseen.
They were/are an attempt to help effectively organize and communicate
such "best practices" by lending them a name to facilitate discussion
and build a shared vocabulary, and by suggesting a particular way to
convey the underlying motivation and insight, in hopes that it might
communicate some uncommon wisdom regarding such commonly recurring
solutions. Then perhaps one might better understand not only that
the particular solution works, but have a deeper appreciation of
why it works and why it recurs. The purpose was to deepen existing
knowledge, not to replace it.
That doesn't mean that everyone succeeded in such attempts, or that
everyone who made an attempt had altruistic motives, but the purpose
was *never* to pass them off as new practice, or even a new name for an
old practice. It may have been done by newbies and hucksters, but that
sort of thing always happens no matter what the "flavor of the month"
happens to be (patterns or otherwise). This particular instance of the
"tragedy of the commons" happened just as much for "O-O" and "Java" and
"Components" every bit as much as it has for "patterns."
--
Brad Appleton <bra...@enteract.com> | http://www.enteract.com/~bradapp/
"And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng
Ell
>In article <MPG.10884755b...@netnews.worldnet.att.net>,
> To...@ask.me (Tony) writes:
>
>> I'm don't think a "consistent format" has been accepted ...
>
>Actually, there are 2-3 of them that have been commonly accepted.
>Perhaps you meant to say no single consistent format has been accepted.
>
>> "Design". The concern is that the slightly new term (adding "patterns")
>> is an attempt to make the practice appear as something "NEW" when it's
>> not.
>
>But the term "patterns" isn't at all new. It was a 20+ year old term
>borrowed from another field and applied to software. The application
>in this domain was new, the name and concept were anything but.
Actually the term is older than that. My mom used what were
explicitly called "patterns" to sew and create dresses back in the
'60's and I'm fairly certain patterns were around in sewing for
decades before that.
>That doesn't mean that everyone succeeded in such attempts, or that
>everyone who made an attempt had altruistic motives, but the purpose
>was *never* to pass them off as new practice, or even a new name for an
>old practice. It may have been done by newbies and hucksters, but that
>sort of thing always happens no matter what the "flavor of the month"
>happens to be (patterns or otherwise). This particular instance of the
>"tragedy of the commons"
Or perhaps of the hucksters who exploited and broke up the commons
solely for personal gain.
> happened just as much for "O-O" and "Java" and
>"Components" every bit as much as it has for "patterns."
On the mark, ;-}
Elliott
--
:=***=: VOTE NO TO MODERATION! :=***=:
CRAFTISM SHOULD NOT USE USENET RESOURCES TO AVOID CRITICISM!
MODERATORS SHOULD NOT HAVE LIFETIME TERMS!
:=***=: Objective * Pre-code Modelling * Holistic :=***=:
Hallmarks of the best SW Engineering
Study Phony Crafite OO vs. Genuine OO: http://www.access.digex.net/~ell
Copyright 1998 Elliott. exclusive of others' writing. may be copied
without permission only in the comp.* usenet and bitnet groups.
Tony
> Fair enough. Still, your claim to make a judgement on "most
> patterns" is still questionable, unless you claim to be familiar
> with most patterns.
"Questionable" but definitely not "inplausible". That kind of decision
making happens at a more abstract level then just the domain of the
single product called "design patterns" and synthesizes all previous life
experience. In other words, other "patterns" (outside the box) are
brought into the decision making (or opiniating) process.
> >The two popular texts have been on my shelf for over a year at least.
> >Certainly one of them (I forgot which) gives the impression of poorly
> >thought out presentation and too much of an attempt to come up with a
> >consistent format that makes it overly verbose if not repetitive. (Not
> >to say that the _information_ contained within is not useful, just that
> >it's organization was poor (opinion)).
>
> Interesting, but what's the relevance?
Just that I didn't hear it for the first time recently and have at least
_some_ familiarity. Also, for a practice touting to be one of reuse,
it's kinda interesting that one of the tomes is in less than an
optimum format for assimiliation (opinion again).
> >> >Intra-
> >> >company this is useful. Inter-company reuse is better done via
> >> >components.
> >>
> >> Why is that? Just a few posts ago you told us that code reuse was
> >> passe. Now it's the preferred way to get inter-company reuse?
> >
> >My, my .. isn't someone out for blood now. Reread the statement. It
> >says: Intra-company reuse ok at source code level; Inter-company reuse ok
> >at component level. Perhaps you don't know "intra-" vs. "inter-"?
>
> Actually, the "this" in "this is useful" was (unless I'm mistaken)
> referring to the implementation design you referred to in your
> previous paragraph. Also, it seems (correct me if I'm wrong) that
> by "components" you mean compiled binaries, and I didn't read that
> into it. So your statement, to me, read "intra-company,
> implementation design reuse is useful. Inter-company reuse is
> better done via code reuse". You see how I came to the conclusion
> I did?
How could you come up with "Inter-company reuse is better done via code
reuse" when I EXPLICITELY wrote: "Inter-company reuse is better done via
components"? And in the context that would have made my post wrong by
nature of the redundancy. (You should have realized that _I'm_ never
wrong! ;) )
> Anyway, if you're now saying that source code reuse is good within
> a company while between companies, binary reuse is better, that still
> seems nonsensical to me. Could you explain why this is?
No (I don't want to explain), just because I don't want to open a can of
worms and also, the answer is all around you at this late juncture in the
industry (I won't do your required reading/studying for you). Are you
familiar with the attraction the industry has with component technology?
> And, what does all this have to do with design patterns? They
> are concerned neither with code reuse nor with binary reuse.
AGAIN, the patterns "movement" is based upon reuse at less than an
optimal level (it's still "twiddling bits" at the level or in the realm
of source code/design so lets just say it's "less important" than, for
instance, component assembly). It's programming/development rather than,
say, "assembly".
Tony
Tony
> Tony wrote:
> >
> > In article <F0JBC...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
> > >
> > > Ok, what's the existing terminology for "design pattern"?
> >
> > is an attempt to make the practice appear as something "NEW" when it's
> > not.
>
> patterns as analogous to design patterns.
>
> A sewing pattern is not a garment, it is a guide to how to make many
> variants of a garment. One hundred different people can use the
> same pattern and make one hundred different garments, each useful
> in the same way.
>
> So, deciding how to lay out your specific garment is the counterpart
> to design. This is different than the sewing pattern you use to lay
> out the garment, which is the counterpart to the design pattern.
I know, but I'll keep the colloquialism I think. You made me realize
though why some designers are better than others: because they've always
done design with reuse in mind (in many of their designs anyway).
Personally, when I've done those things, THAT was what made it fun.
Tony
Tony
> In article <MPG.10884755b...@netnews.worldnet.att.net>,
> To...@ask.me (Tony) writes:
>
> > I'm don't think a "consistent format" has been accepted ...
>
> Actually, there are 2-3 of them that have been commonly accepted.
Did you mean in published texts rather than in practice?
Tony
Tony
> everyone who made an attempt had altruistic motives, but the purpose
> was *never* to pass them off as new practice, or even a new name for an
> old practice. It may have been done by newbies and hucksters, but that
> sort of thing always happens no matter what the "flavor of the month"
> happens to be (patterns or otherwise). This particular instance of the
> "Components" every bit as much as it has for "patterns."
My guess is that "pattern" (the term) won't find a status such as "OO" or
"components" just because of the closesness to (not enough of a step
from) the practice of design. This IS my point.
Tony
Tony
> In article <MPG.10884a211...@netnews.worldnet.att.net>,
> >
> >Source reuse is a "micro-" process that has proven to be too unwieldly to
> >be practical as the primary level of reuse management. (It pushes
> >certain management responsibility to the programmer level where it's not
> >necessarily desireable). Design level reuse is only incrementally better
> >and still to low level. Component level reuse seems to have the correct
> >attributes and potentials (I'll leave that dialog as an excercise for the
> >reader). Clear as mud yet?
>
> of abstraction from design reuse? Now *that* is the part I don't get.
> :-)
Perhaps the word "abstraction" is better not used in the dialog here.
Components manage complexity at a higher level. See the stepping stones?
Designs manage complexity of implementation (e.g. source code) and
components "one up" design (kinda, the progression is not the same).
Tony
Tony
ibm.net says...
> In article <F0o3y...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
> > In article <MPG.10884a211...@netnews.worldnet.att.net>,
> > I think I get it. You consider component reuse to be at a higher level
> > of abstraction from design reuse? Now *that* is the part I don't get.
> > :-)
>
> They have a much higher level of reuse than components.
No, "patterns" still are at an early point in the life cycle. Components
are real, not just wishful thinking. You can use a component immediately
but you have to build what your "pattern" describes abstractly. Anyway,
this thread was fueled on the point that "patterns" are at the same level
as coding (it's basically design).
A design that is implemented for reuse, perhaps via components, can be
said to have reuse potential on the level of component technology. But
certainly one can't claim a design described in a "pattern" book puts you
farther along than something already implemented that can be used simply
via configuration.
Tony
Brad Appleton
To...@ask.me (Tony) writes:
>My guess is that "pattern" (the term) won't find a status such as "OO"
>or "components" just because of the closesness to (not enough of a step
>from) the practice of design.
Only time will tell.
> This IS my point.
Okay, but your point for/against what? You seemed to be trying to make
this point in response to some other argument, but I don't recall anyone
saying much to the contrary on that particular point. They responded to
other aspects of your postings which seemed to be well deserved but
overly stated backlash against the current patterns hype.
I don't think patterns were intended to promote the kind of reuse you
seem to. They're not about cookbook reuse of a pat solution or even an
existing component so much as they are about reusing experience and
insight (perhaps about design/components, though not necessarily being
the design/component itself).
Patterns are about understanding and communicating the how and why (and
when) of solutions. The knowledge being reused via a pattern is not so
much the solution itself, as it is the knowledge of when to use it,
what motivates it, causes it, shapes it, and underlies its recurring
successful use. The solution itself might be reusable in design, or
code, or executable form. The pattern is not the solution so much as it
is the information surrounding that solution. The solution is just the
manifestation of sound principles and certain forces/constraints in a
given scenario. The pattern attempts to use the concrete solution to
convey the interplay of principles and forces in the given context.
This is complementary to design/code reuse, not competitive.
Tony
says...
> In article <MPG.108cabe1d...@netnews.worldnet.att.net>,
> To...@ask.me (Tony) writes:
> >My guess is that "pattern" (the term) won't find a status such as "OO"
> >or "components" just because of the closesness to (not enough of a step
> >from) the practice of design.
>
> Only time will tell.
But in the mean time, I'll draw my own conclusions (and I'm a real good
guesser, I should play the stock market).
> > This IS my point.
>
> Okay, but your point for/against what? You seemed to be trying to make
> this point in response to some other argument, but I don't recall anyone
> saying much to the contrary on that particular point. They responded to
> other aspects of your postings which seemed to be well deserved but
> overly stated backlash against the current patterns hype.
Actually, the whole debate started with the "refactoring" term. My
perspective probably holds more weight there than in the "patterns"
realm. And I wasn't the one to pursue the debate either. Some just came
to the defense of the fledgling ;) paradigms.
> I don't think patterns were intended to promote the kind of reuse you
> seem to. They're not about cookbook reuse of a pat solution or even an
> existing component so much as they are about reusing experience and
> insight (perhaps about design/components, though not necessarily being
> the design/component itself).
And my point therefor is that, that incremental process/definition
improvement is way down on the pareto list. I'm not so concerned about
the format of communication of the invention as much as the actual
invention. Scribble it on a napkin if you want. If it's good, it'll
catch on.
> Patterns are about understanding and communicating the how and why (and
> when) of solutions. The knowledge being reused via a pattern is not so
> much the solution itself, as it is the knowledge of when to use it,
> what motivates it, causes it, shapes it, and underlies its recurring
> successful use. The solution itself might be reusable in design, or
> code, or executable form. The pattern is not the solution so much as it
> is the information surrounding that solution. The solution is just the
> manifestation of sound principles and certain forces/constraints in a
> given scenario. The pattern attempts to use the concrete solution to
> convey the interplay of principles and forces in the given context.
Well you've described an umbrella for sure but it's not the "patterns"
umbrella. It's good to transfer knowledge but there are many ways of
doing that and "patterns" aren't significantly different from the
majority of them (nothing new). Indeed, one might even want to make the
case that rigid structure can constrain and limit the communicative
process by not optimizing the transmission medium for the given
situation. Also, instead of inductively trying to match the solutions to
problems, perhaps it's better to focus on the categories of problems and
list the potential solutions.
Overall though, "patterns" just doesn't "feel" right. Perhaps it's that
inside-out perspective that is troublesome. Or probably because I don't
feel such basic though processes need to be emphasized. Anyway, I've got
too far into (too much time in) this discussion for my priorities. If
authors want to call them "patterns" fine, but I don't recognize the
paradigm (also "refactoring") as primary or new or of significant
relevance relative to "more important" things.
Not that the ideas don't have any merit though; The paradigms would be
more important in training those who don't yet know how to think
creatively or who have never built anything or don't have already
established paradigms for such basic but abstract processes. Analogous
to the "learn how to learn" classes. e.g. Of course, if you ask me,
inventing the new terminology adds confusion to the newbies and perhaps
overemphasizes where (in what domain) the information about "patterns"
and "refactoring" resides. (There's a good exercise question in that
last sentence for "the reader" or those wanting to define the paradigms).
Tony
Michael J. Tobler
To...@ask.me says...
[snip]
> No, "patterns" still are at an early point in the life cycle. Components
> are real, not just wishful thinking. You can use a component immediately
> but you have to build what your "pattern" describes abstractly. Anyway,
> this thread was fueled on the point that "patterns" are at the same level
> as coding (it's basically design).
and language) references after the analysis stage (sometimes there too),
while moving into detail design (and before coding).
> A design that is implemented for reuse, perhaps via components, can be
> said to have reuse potential on the level of component technology. But
> certainly one can't claim a design described in a "pattern" book puts you
> farther along than something already implemented that can be used simply
> via configuration.
No, but the pattern can help you to build the construct quicker with less
pain. Also, a pattern spans various domains, such as architectural,
business, and application. Most components are hard to get reuse unless
they are at the foundation level. The more domain specific (architectural,
business, and application), the harder it is to reuse the component.
Tony
ibm.net says...
> In article <MPG.108caf3d...@netnews.worldnet.att.net>,
> To...@ask.me says...
> [snip]
> > No, "patterns" still are at an early point in the life cycle. Components
> > are real, not just wishful thinking. You can use a component immediately
> > but you have to build what your "pattern" describes abstractly. Anyway,
> > this thread was fueled on the point that "patterns" are at the same level
> > as coding (it's basically design).
> Patterns on the same level as coding? Hmmm. I turn to the pattern (design
> and language) references after the analysis stage (sometimes there too),
> while moving into detail design (and before coding).
I meant relatively (relative to component assembly for instance). All
those you mentioned can be bunched together. They're basically intricate
development work. When working at the component assembly/configuration
level, you're really moving along rapidly. But in the development life
cycle, you're back at that "it's 90% done so now we have 10% of the time
the project will take under our belts".
> > A design that is implemented for reuse, perhaps via components, can be
> > said to have reuse potential on the level of component technology. But
> > certainly one can't claim a design described in a "pattern" book puts you
> > farther along than something already implemented that can be used simply
> > via configuration.
> No, but the pattern can help you to build the construct quicker with less
> pain. Also, a pattern spans various domains, such as architectural,
> business, and application. Most components are hard to get reuse unless
> they are at the foundation level. The more domain specific (architectural,
> business, and application), the harder it is to reuse the component.
But the time, resources, risk etc. are like night and day. Component
reuse sounds like "almost done". Design patterns sounds like "R&D time".
Get my drift?
Tony
Dave Boutilier
Tony wrote in message ...
>In article <MPG.108ddbdec...@news3.ibm.net>, mtobler@no-spam-
>ibm.net says...
>> In article <MPG.108caf3d...@netnews.worldnet.att.net>,
>> To...@ask.me says...
<snip>
>> No, but the pattern can help you to build the construct quicker with less
>> pain. Also, a pattern spans various domains, such as architectural,
>> business, and application. Most components are hard to get reuse unless
>> they are at the foundation level. The more domain specific
(architectural,
>> business, and application), the harder it is to reuse the component.
>
>But the time, resources, risk etc. are like night and day. Component
>reuse sounds like "almost done". Design patterns sounds like "R&D time".
>Get my drift?
>
>Tony
You aren't talking about the same thing. Any project that can be fully
implemented using available components is probably sufficiently trivial that
neither design patterns nor any form of OOA&D would be required.
Patterns, and good software engineering methodology, provide benefits for
projects requiring a substantial amount of work to build new objects and
components. They aren't much help if all you need to do is display a
message.
"Hello, world" does not require a lot of design (unless you're using MFC.)
Please stop trying to provoke (yet another) flame war.
Brad Appleton
To...@ask.me (Tony) writes:
>In article <70083j$22...@nntp.cig.mot.com>, bra...@enteract.mot.com
>says...
>> seem to. They're not about cookbook reuse of a pat solution or even an
>> existing component so much as they are about reusing experience and
>> insight (perhaps about design/components, though not necessarily being
>> the design/component itself).
>
>And my point therefor is that, that incremental process/definition
>improvement is way down on the pareto list. I'm not so concerned about
>the format of communication of the invention as much as the actual
>invention. Scribble it on a napkin if you want. If it's good, it'll
>catch on.
But catch on *how*? By people simply using it blindly without even the
first clue as to its appropriateness or suitability or limitations?
Some will try to do it this way and will get very unproductive results.
And the same is true of components - reuse of anything requires some
degree of understanding apparently more than many seem willing to invest.
>> Patterns are about understanding and communicating the how and why (and
>> when) of solutions. The knowledge being reused via a pattern is not so
>> much the solution itself, as it is the knowledge of when to use it,
>> what motivates it, causes it, shapes it, and underlies its recurring
>> successful use. The solution itself might be reusable in design, or
>> code, or executable form. The pattern is not the solution so much as it
>> is the information surrounding that solution. The solution is just the
>> manifestation of sound principles and certain forces/constraints in a
>> given scenario. The pattern attempts to use the concrete solution to
>> convey the interplay of principles and forces in the given context.
>
>Well you've described an umbrella for sure but it's not the "patterns"
>umbrella.
Yes it is (honest). Some of the difficulty that people have in
grasping this is the fact that its in stark contrast with the more
popularly used modes for describing common knowledge about common
solutions to problems (clues for the clueless), or describing uncommon
knowledge about uncommon solutions to problems (state of the
art/research). Patterns are supposed to be about describing uncommon
knowledge about common solutions to common problems.
Surprisingly enough, its apparently so different (or else unexpected)
in its intent and motivation from the other two formats that those
deeply entrenched in the other two often have great difficulty
understanding/accepting this difference and their value. (But absence
of evidence does not imply evidence of absence ;-)
> Indeed, one might even want to make the case that rigid structure
[snip]
The format need not be rigid (and often isn't). Thats an artifact of
folks mistaking the pattern to be a document template (its not).
>Also, instead of inductively trying to match the solutions to problems,
[snip]
Such inductive matching is by no means prescribed by patterns. Some
attempt to use them that way (which is dangerously close to a "cookbook"
approach clamoring for instant gratification) but it isn't necessarily
the best or even recommended approach (much less the "patterns" way).
>perhaps it's better to focus on the categories of problems and
>list the potential solutions.
Which is actually one of the things Alexander discusses when describing
patterns and pattern languages. Again, the misplaced focus is not
necessarily being emphasized or recommended by patterns. Often its
simply misunderstood to be the case.
>Overall though, "patterns" just doesn't "feel" right. Perhaps it's that
>inside-out perspective that is troublesome.
And just how is it _supposed_ to feel? What "inside-out" perspective
are you referring to (and what makes you so sure its a characteristic
of patterns rather than simply a possible misunderstanding or
misapplication)?
> Or probably because I don't feel such basic though processes need
> to be emphasized.
Its not the thought processes that are being emphasized. Some of the
things being emphasized are certainly basic, but what is most assuredly
not basic to any but the expert is WHY those things are basic and why
they recur and why they end up working that way. If you're already an
expert, then you're absolutely right, its nothing new - and its not SUPPOSED
to be new if thats the case.
The purpose is to communicate the kind of "why and wherefore" behind
the sort of judgement and solutions that the master practitioners have
come to do instinctively. That stuff is only basic if you're already
well on the way to being a master. If you are, great. If not, it is
extremely useful. And that is precisely the audience that the patterns
are supposedly for.
>too far into (too much time in) this discussion for my priorities. If
>authors want to call them "patterns" fine, but I don't recognize the
>paradigm (also "refactoring") as primary or new or of significant
>relevance relative to "more important" things.
New? Definitely not (and neither is the terminology). Primary or
significant relevance to "more important things" is entirely
subjective. But if OOD and frameworks and their maintainability &
adaptability is on your "pareto" list of priorities, refactoring is
nothing less than quintessential (I'd recommend Brian Foote's and Bill
Opdyke's writing on the topic - see http://laputa.isdn.uiuc.edu/, and
while you're at it, check out "Novelty Vampires" ;-) It may seem basic
to those in the know. But if it were as basic as you claim, it would be
the norm (which would be great, but is unfortunately not the case).
Tony
says...
>
> Tony wrote in message ...
> >In article <MPG.108ddbdec...@news3.ibm.net>, mtobler@no-spam-
> >ibm.net says...
> >> In article <MPG.108caf3d...@netnews.worldnet.att.net>,
> >> To...@ask.me says...
>
> <snip>
>
>
> >> No, but the pattern can help you to build the construct quicker with less
> >> pain. Also, a pattern spans various domains, such as architectural,
> >> business, and application. Most components are hard to get reuse unless
> >> they are at the foundation level. The more domain specific
> (architectural,
> >> business, and application), the harder it is to reuse the component.
> >
> >But the time, resources, risk etc. are like night and day. Component
> >reuse sounds like "almost done". Design patterns sounds like "R&D time".
> >Get my drift?
> >
> >Tony
>
> You aren't talking about the same thing.
Exactly.
> Any project that can be fully
> implemented using available components is probably sufficiently trivial that
> neither design patterns nor any form of OOA&D would be required.
The thought was hypothetical. But the future will hold...
> Patterns, and good software engineering methodology, provide benefits for
> projects requiring a substantial amount of work to build new objects and
> components. They aren't much help if all you need to do is display a
> message.
Agreed. Starting with a know design (drawing upon experience is always
good). But that's been the case for millions of years. It didn't just
now start because someone wants to call it "design patterns" instead of
"design".
> Please stop trying to provoke (yet another) flame war.
I'm not! YOU'RE just not getting it. You're too busy trying to compare
apples to apples when the concepts involved here are more abstract or at
a higher level. Try to think like a project manager or a business leader
and it might help. Development leader A says: "Yes, I know just the
patterns I can use to build the system". Development leader B says: "I
have most of those components to build the system already". Who's going
to lead that project?
No more on this from me.
Tony
Jeff Younker
> Agreed. Starting with a know design (drawing upon experience is always
> good). But that's been the case for millions of years. It didn't just
> now start because someone wants to call it "design patterns" instead of
> "design".
>
> > Please stop trying to provoke (yet another) flame war.
I don't see 'Design Patterns' and 'Components' as being
either mutually exclusive or competing. They seem to me
to be complementary.
'Design Patterns' provide a common set of terminology for
software architecture. This shared terminology allows the
component vendor to describe how the developer's "glue" code
interacts with a component.
What follows is a description from mythological documentation
for a mythological component. The component is described in
terms of design patterns. I think that it gives an idea of
how the component is used even though it specifies no
details. I can't really see a means of conveying the same
information in such a concise and clear manner without
resorting to the terminology of design patterns, but that may
just be a failing on my part.
'Component X processes Widgets (see class Widget. The
component is initialized with a Widget factory (see
class WidgetFactory), and it is an observer of the
Widgets which this factory produces. Users of X will
have to implement both observable Widgets (see class
Observable) and a Factory for those Widgets.'
- Jeff Younker - je...@mdli.com - These are my opinions, not MDL's -
Dave Boutilier
Tony wrote in message ...
>I'm not! YOU'RE just not getting it. You're too busy trying to compare
>apples to apples when the concepts involved here are more abstract or at
>a higher level. Try to think like a project manager or a business leader
>and it might help. Development leader A says: "Yes, I know just the
>patterns I can use to build the system". Development leader B says: "I
>have most of those components to build the system already". Who's going
>to lead that project?
B, obviously. And the project will crash and burn when they discover that
_all_ of the necessary components don't exist, or aren't quite fit for the
purpose, or are defective. Components can alleviate drudgery, and can
contribute to building a solution, but they are not likely to be of much use
in establishing or implementing the high-level design of a system of any
complexity.
What is it I'm not getting here, Tony? Components occupy a useful niche,
but just aren't robust when heavy lifting is needed. Project after project
explores their use, and project after project ends up discarding,
reimplementing or "coding around" them. Except for specialized pieces,
where a highly stylized solution is definable, components look pretty weak.
Incidentally, vague insinuations about my inability to grasp abstract or
higher-level concepts are no way to conduct an argument. Much more of that,
and there will be a second reason to migrate over to c.o.m. When there are
deficiencies in my arguments or reasoning, by all means point them out.
But, BE SPECIFIC! I have difficulty with abstract concepts ;-)
Jeff Younker
> In article <361AC6E2...@ibm.net>, biju...@ibm.net says...
> > May be large companies have been documenting and distributing design
> > techniques among their own people. But what the pattern movement (I
> > could not find a better term for it) is doing is popularizing valuable
> > and commonly used design methods, so that everyone doesn't have to
> > reinvent the wheel. This knowledge dissemination may be against the
> > interests of some corporations, but it is in the interest of whole
> > society to do so.
>
> This is the GPL spiel. Most people fall into one category or the other:
> ...
Perhaps "society as a whole" is overly broad, and the "society of
software developers as a whole" is more appropriate, but jihuthom's
point is quite accurate. Our employer's best interests are rarely
precisely in line with our own. Just as there may be cases in which
both interests are in precise alignment, there are instances in
which our interests are in direct opposition...
Communicating the information that jihuthom writes about
may not necessarily be in a company's best interests, but it is definitely
in OUR best interests as developers. The faster that we can
produce reliable, robust, maintainable software for our employers
the more money we can make, and the easier it is to get/keep a job.
> > About they inventing new terms for describing these techniques - it is
> > easier to communicate with others if all agree on some basic
> > terminology.
>
> Yep, but better still if you can use EXISTING terminology.
I may just not be very well read, but I never encountered any existing
terminology for the structures that "Design Patterns" cover.
> > We would not ask mathematicians to avoid using terms like
> > ring, group etc. Software community is also entitled to such rights.
>
> Invention of new terminology needs to be the exception rather than the
> rule. Don't pollute the namespace. :)
The name "Design Patterns" might be better off as "Architectural
Structures" or some such, but as a term goes it's a slightly more
informative than "Galois Theory."
Robert C. Martin
Jeff Younker wrote in message ...
>To...@ask.me (Tony) writes:
>
>> Agreed. Starting with a know design (drawing upon experience is always
>> good). But that's been the case for millions of years. It didn't just
>> now start because someone wants to call it "design patterns" instead of
>> "design".
>>
>> > Please stop trying to provoke (yet another) flame war.
>
>I don't see 'Design Patterns' and 'Components' as being
>either mutually exclusive or competing. They seem to me
>to be complementary.
Yes, that's quite right. Design patterns and components are completely
orthogonal concepts.
Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
Biju Thomas
>
> The name "Design Patterns" might be better off as "Architectural
> Structures" or some such, but as a term goes it's a slightly more
> informative than "Galois Theory."
>
Well, 'Galois Theory' is named after the inventer of the theory. Why do
theories (or equivalent things) in software doesn't get named after the
inventer? The names of the theories in computer science generally convey
what it is about than who originated it. Is it because computer
scientists are not individualistic compared against others?
Regards,
Biju Thomas
Tony
says...
>
> Tony wrote in message ...
> <snip>
> >I'm not! YOU'RE just not getting it. You're too busy trying to compare
> >apples to apples when the concepts involved here are more abstract or at
> >a higher level. Try to think like a project manager or a business leader
> >and it might help. Development leader A says: "Yes, I know just the
> >patterns I can use to build the system". Development leader B says: "I
> >have most of those components to build the system already". Who's going
> >to lead that project?
>
> B, obviously. And the project will crash and burn when they discover that
> _all_ of the necessary components don't exist, or aren't quite fit for the
> purpose, or are defective. Components can alleviate drudgery, and can
> contribute to building a solution, but they are not likely to be of much use
> in establishing or implementing the high-level design of a system of any
> complexity.
C'mon, just agree without contriving a scenario just to be argumentative.
My scenario attempted to reach for the _goal_, however ideal it may seem
to you.
> What is it I'm not getting here, Tony? Components occupy a useful niche,
> but just aren't robust when heavy lifting is needed. Project after project
> explores their use, and project after project ends up discarding,
> reimplementing or "coding around" them. Except for specialized pieces,
> where a highly stylized solution is definable, components look pretty weak.
There you go again focusing on "components" when I just used it as an
example of the indication of a more a mature level of operation.
> Incidentally, vague insinuations about my inability to grasp abstract or
> higher-level concepts are no way to conduct an argument.
Twas not "a slam" or general statement (I don't know you). Twas a
specific observation described above. (I can see how you easily slipped
into the mode of thinking to produce your above line given all the
associated topics in our immediate dialog. That fed the pattern your
mind put together. It was an incorrect synthesis though (your intuition
was wrong this time. Nice example situation, BTW!).
> Much more of that,
> and there will be a second reason to migrate over to c.o.m. When there are
> deficiencies in my arguments or reasoning, by all means point them out.
> But, BE SPECIFIC! I have difficulty with abstract concepts ;-)
Reread the above. But mostly: lighten up!
Tony
"When I'm being an SOB, you'll know it for sure!"
- unknown
Tony
> To...@ask.me (Tony) writes:
>
> > Agreed. Starting with a know design (drawing upon experience is always
> > good). But that's been the case for millions of years. It didn't just
> > now start because someone wants to call it "design patterns" instead of
> > "design".
> >
> > > Please stop trying to provoke (yet another) flame war.
>
> I don't see 'Design Patterns' and 'Components' as being
> either mutually exclusive or competing. They seem to me
> to be complementary.
I'm not even going to read the rest of this post because if you're taking
the reference to "components" in the above context, then you've missed
the point completely.
Never mind then or "skip it", it's not worth the time.
Tony
Avner Ben
patterns are useful and important.
Reference to design patterns makes the design specification shorter and more
concise. It allows the removal of large chunks of redundant technical
specification to the phase of implementation by simply mentioning the use of
a certain design pattern, perhaps with some welcome notes, and leave the
details for the implementor. Elements from a design-pattern implementation
must float into high-level design only where classes involved with a pattern
may not be ignored in the data-model. E.g., the (normally three) classes
involved with the composite pattern may not be ignored in the data-model.
(unless someone invents a symbol for entity-recursion). The fact that there
is likely to be a fat interface at the base and the rationale for doing so
may go away. As more design-patterns become wide-spread and accepted, design
specifications may grow concise and puctual, representing mostly the
application domain and less and less solution-related additions, because
these will be taken care of by well-tested design patterns. Of-course, the
implementation of the pattern will leave much for the implementor - this is
not a mechanical expansion, but it may be tolerated were it has little
feedback to the design. I have found that good design patterns are like
that.
Why is it so important for design specifications to be short, concise,
laconic, punctual? Flexibility. The ability to endure changes. The less
redundant detail, with all its backward dependencies, the easier to adjust!
Avner.
Patrick Doyle
Tony <To...@ask.me> wrote:
>
>In article <705frq$6on$1...@news.ipa.net>, david.b...@bigfoot.com
>says...
>>
>> _all_ of the necessary components don't exist, or aren't quite fit for the
>> purpose, or are defective. Components can alleviate drudgery, and can
>> contribute to building a solution, but they are not likely to be of much use
>> in establishing or implementing the high-level design of a system of any
>> complexity.
>
>C'mon, just agree without contriving a scenario just to be argumentative.
Have you had *all* the pre-made components you ever needed for every
project you've ever worked on? If the answer is "no" then David's
scenario is not contrived, and you're blowing hot air.
If the answer's "yes" then you're one lucky SOB.
>There you go again focusing on "components" when I just used it as an
>example of the indication of a more a mature level of operation.
Components are not a "more mature level of operation", any more than
bricks are a more mature way to build a house. You still need
design.
-PD
--
--
Patrick Doyle
doy...@ecf.toronto.edu
Patrick Doyle
Tony <To...@ask.me> wrote:
>
>Development leader A says: "Yes, I know just the
>patterns I can use to build the system". Development leader B says: "I
>have most of those components to build the system already". Who's going
>to lead that project?
Yeah, who's going to build the house first: the guy with a truckload
of bricks, or the contractor who knows how to put them together?
Tony
How much skill is needed to put together a prefab house?
Tony
--
Post DIRECT job and contract opportunities to
alt.computer.consultants.ads.norecruiters and eliminate middleman costs!
Tony
> In article <MPG.10906195b...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
> >
> >In article <705frq$6on$1...@news.ipa.net>, david.b...@bigfoot.com
> >says...
> >>
> >> B, obviously. And the project will crash and burn when they discover that
> >> _all_ of the necessary components don't exist, or aren't quite fit for the
> >> purpose, or are defective. Components can alleviate drudgery, and can
> >> contribute to building a solution, but they are not likely to be of much use
> >> in establishing or implementing the high-level design of a system of any
> >> complexity.
> >
> >C'mon, just agree without contriving a scenario just to be argumentative.
>
> Have you had *all* the pre-made components you ever needed for every
> project you've ever worked on? If the answer is "no" then David's
> scenario is not contrived, and you're blowing hot air.
What's the goal Patrick, always starting from the code level or achieving
reuse??
> Components are not a "more mature level of operation", any more than
> bricks are a more mature way to build a house. You still need
> design.
OK, but *you* start by planting seedlings and wait for the trees to grow
so you can cut them down, make 2x4s out of them and frame the house. In
the mean time though, you go out and mine copper so that you can make
plumbing and electrical wire ... It's gonna be awhile before you're out
of the rain.
Patrick Doyle
Tony <To...@ask.me> wrote:
>In article <F0y4L...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
>>
>> Yeah, who's going to build the house first: the guy with a truckload
>> of bricks, or the contractor who knows how to put them together?
>
>How much skill is needed to put together a prefab house?
Are you saying it doesn't take much skill? And by saying so, are
you implying it doesn't take much skill to build software from
components?
If so, then I think you've proven my point by reductio ad absurdum
on your own argument!
Patrick Doyle
Tony <To...@ask.me> wrote:
>In article <F0y4x...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
>>
>> Have you had *all* the pre-made components you ever needed for every
>> project you've ever worked on? If the answer is "no" then David's
>> scenario is not contrived, and you're blowing hot air.
>
>What's the goal Patrick, always starting from the code level or achieving
>reuse??
Er, it's reuse. What's your point?
>> Components are not a "more mature level of operation", any more than
>> bricks are a more mature way to build a house. You still need
>> design.
>
>OK, but *you* start by planting seedlings and wait for the trees to grow
>so you can cut them down, make 2x4s out of them and frame the house. In
>the mean time though, you go out and mine copper so that you can make
>plumbing and electrical wire ... It's gonna be awhile before you're out
>of the rain.
I'd like to know how you got the impression that I want to "wait for
the trees to grow".
Let me spell it out:
To build a house (or software system) you need components *and* design.
Neither is superior. Both are necessary.
Tony
> In article <MPG.10921b60b...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
> >In article <F0y4x...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
> >>
> >> Have you had *all* the pre-made components you ever needed for every
> >> project you've ever worked on? If the answer is "no" then David's
> >> scenario is not contrived, and you're blowing hot air.
> >
> >What's the goal Patrick, always starting from the code level or achieving
> >reuse??
>
> Er, it's reuse. What's your point?
That something already built (like a component) puts you way ahead of the
game. The discussion points were focused on the goal as the someone
brought up the unfortunate direct comparison of designs (apples) vs.
components (oranges). That stemmed from my using components as an
example of a potentially more important technology today than best
practice improvement of the design process (patterns).
> >> Components are not a "more mature level of operation", any more than
> >> bricks are a more mature way to build a house. You still need
> >> design.
> >
> >OK, but *you* start by planting seedlings and wait for the trees to grow
> >so you can cut them down, make 2x4s out of them and frame the house. In
> >the mean time though, you go out and mine copper so that you can make
> >plumbing and electrical wire ... It's gonna be awhile before you're out
> >of the rain.
>
> I'd like to know how you got the impression that I want to "wait for
> the trees to grow".
>
> Let me spell it out:
>
> To build a house (or software system) you need components *and* design.
> Neither is superior. Both are necessary
My scenario had designs at the pre-code level (design of components
instead of component systems). That's probably not such a big reach.
Surely we will be designing component-based systems eventually, but right
now design means R&D and a low level of reuse (built from scratch) on
most projects.
Tony
> In article <MPG.10921a0d9...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
> >In article <F0y4L...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
> >>
> >> Yeah, who's going to build the house first: the guy with a truckload
> >> of bricks, or the contractor who knows how to put them together?
> >
> >How much skill is needed to put together a prefab house?
>
> Are you saying it doesn't take much skill? And by saying so, are
> you implying it doesn't take much skill to build software from
> components?
>
> If so, then I think you've proven my point by reductio ad absurdum
> on your own argument!
I'm saying that _relatively_ it takes (will take) much less than building
from scratch.
Patrick Doyle
Tony <To...@ask.me> wrote:
>In article <F11B7...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
>>
>> Are you saying it doesn't take much skill? And by saying so, are
>> you implying it doesn't take much skill to build software from
>> components?
>
>from scratch.
Ok, if you have good components, it takes less skill to build the
same system. So, once we have great components, people will want
to build *better* systems, so the demand for design skill will
always exist.
So, trying to codify aspects of design (as design patters attempt
to do) will be valuable until design becomes totally obsolete.
Tony
> In article <MPG.10945c363...@netnews.worldnet.att.net>,
> Tony <To...@ask.me> wrote:
> >In article <F11B7...@ecf.toronto.edu>, doy...@ecf.toronto.edu says...
> >>
> >> Are you saying it doesn't take much skill? And by saying so, are
> >> you implying it doesn't take much skill to build software from
> >> components?
> >
> >I'm saying that _relatively_ it takes (will take) much less than building
> >from scratch.
>
> Ok, if you have good components, it takes less skill to build the
> same system. So, once we have great components, people will want
> to build *better* systems, so the demand for design skill will
> always exist.
And at about the same time, many of those calling themselves programmers
will be at minimum wage since reuse of components will create an industry
where the need for heads-down programmers will be less overall. ;)
> So, trying to codify aspects of design (as design patters attempt
> to do) will be valuable until design becomes totally obsolete.
I you need a paradigm and "patterns" "speak to you", by all means bone up
on it. Watch out for "over documentation" though. Having some
philosophy is probably better than having none.
Michael McCarty
> > Er, it's reuse. What's your point?
>
> That something already built (like a component) puts you way ahead of the
> game. The discussion points were focused on the goal as the someone
> brought up the unfortunate direct comparison of designs (apples) vs.
> components (oranges). That stemmed from my using components as an
> example of a potentially more important technology today than best
> practice improvement of the design process (patterns).
It seems to me that you have somewhat idealistic expectations of
component-level reuse.
In my experience, the results of component-level reuse has been mostly a
wash. I do not know of a single commercially-distributed component
library that has been heralded as particularly well-designed by anyone
other than the people that designed it.
More often than not, the problem with component libraries is that they
generally are designed with the lowest common denominator in mind.
Why? Because that's the problem domain where the solution is most
tractable. When you try to extend the design beyond that level, the
design tends to become either frustratingly incomplete, inconsistent or
so complex that noone wants to spend the time to learn it. At that
point, it may be easier to develop it from scratch. Coincidentally
enough, that's generally where component libraries are used -- in places
where the developer is satisfied with lowest-common-denominator
functionality/performance (or, worse, where they have no other choice).
Having said that, I find it odd that you should find components a more
important technology than the design process that goes into them. You
say yourself that someday "we will be designing component-based
systems". Just where do you expect these wonderfully reuseable
components to come from? And what makes you think that patterns won't
play a significant role in the usage of those components? COM and
CORBA, the two most common component architecture paradigms, by their
very definitions imply the use of patterns.
--
--------------------------------+----------------------------------------------
Michael McCarty (mi...@eai.com)| If you pick up a starving dog and make
Engineering Animation Inc. | him prosperous, he will not bite you;
Ames, IA 50010 | that is the principle difference between
Work: (515) 296-9908 | a dog and a man.
http://www.eai.com/ | Mark Twain
Avner Ben
>...
>In my experience, the results of component-level reuse has been mostly a
>wash. I do not know of a single commercially-distributed component
>library that has been heralded as particularly well-designed by anyone
>other than the people that designed it.
buzz-words as cover-names for supposedly "generic" application domains, and
when people come to actually automate them, they find that thery are
actually defining their own versions of the application domain. The result
is that you go out to buy a magic solution for a THIS_TYPE infra-structure
and what you get does not agree - either completely or at all - with what
you have in mind. And if you did not perform an analysis and had come out
with a design specification of what you need in this application domain in
the first place, then the chances are big that you are going to be
dissapointed.
>
>More often than not, the problem with component libraries is that they
>generally are designed with the lowest common denominator in mind.
infra-structure do it with the explicit agreement that they may pay in
performance (for features they do not and which may not be encapuslated out)
or have to construct their own "macros" for a more specific attribute, or
develop and attach their own device-dependent component using the product
"native interface" and it would still be more economical than doing it all
by themselves. May be and may be not - it is the user's responsibility to
check that out first.
>...Coincidentally
>enough, that's generally where component libraries are used -- in places
>where the developer is satisfied with lowest-common-denominator
>functionality/performance (or, worse, where they have no other choice).
Not quite. I thought the historical sources of subroutine libraries and
off-the-shelf software were mainly areas were
(a) where everyone egreed upon how to do it (e.g., math) and
(b) where doing it required extra-ordinary expertese (statistics, immage
processing aids etc.).
I believe the acceptance of software components is very much like the
acceptance of components in other areas and is mainly a matter of culture.
It has two prerequisites:
(a) the general agrement of the nature of particular application
domains. At some stage, a common way of doing it is established and people
who thoughtdifferently abandon their previous ways.
(b) the agreement upon standards.
Where everyone agrees upon how certainthings are done and about the measures
and sizes of the other parts they have to be attached to, then a component
industry may grow in that field. The problems that you complain of may
testify of either an immature attempt (everyone has not yet agreed about the
nature of the domain in the first place) or an attempt at standartization at
the wrong place. Since this is a slow cutlural process, there is no way to
say if a particlar attempts will succeeds and who's standard-draft will win.
Avner.
Patrick Doyle
Tony <To...@ask.me> wrote:
>
>And at about the same time, many of those calling themselves programmers
>will be at minimum wage since reuse of components will create an industry
>where the need for heads-down programmers will be less overall. ;)
Yeah, just like the automobile reduces travelling time, right?
Wrong. When they get cars, people just want to go farther. How
many of us would work 40 kilometers from home if we didn't have
cars? Or go to a cottage 250km from home each weekend?
Likewise, as it gets easier to build programs, that doesn't mean
everyone gets to slack off. The successful people will still
be the ones who work hard. It simply means they'll be able to build
better systems for the same effort; not that they'll expend
less effort to get the same system. (The latter type of person
would quickly go out of business as his competition moved ahead
of him.)
Michael McCarty
<SNIP>
> >More often than not, the problem with component libraries is that they
> >generally are designed with the lowest common denominator in mind.
> There is nothing fundamentally wrong about that. The users of this
> infra-structure do it with the explicit agreement that they may pay in
> performance (for features they do not and which may not be encapuslated out)
> or have to construct their own "macros" for a more specific attribute, or
> develop and attach their own device-dependent component using the product
> "native interface" and it would still be more economical than doing it all
> by themselves. May be and may be not - it is the user's responsibility to
> check that out first.
I did not intend to imply there was anything with designing to the
lowest common denominator. I was making the statement in response to
the prediction that eventually all systems will be designed based on
reuseable component libraries. If that is to be so, then LCD designs
will not be acceptable. The more assumptions a designer makes about how
the component will be used, the less reuseable the component becomes.
>
> >...Coincidentally
> >enough, that's generally where component libraries are used -- in places
> >where the developer is satisfied with lowest-common-denominator
> >functionality/performance (or, worse, where they have no other choice).
> Not quite. I thought the historical sources of subroutine libraries and
> off-the-shelf software were mainly areas were
> (a) where everyone egreed upon how to do it (e.g., math) and
> (b) where doing it required extra-ordinary expertese (statistics, immage
> processing aids etc.).
You are talking about subroutine libraries not component libraries.
Subroutine libraries are generally more successful mainly because while
the functions may be related, they generally do not interoperate in a
dynamic context (you tend to deal with concrete instances rather than
abstract interfaces). Also, their problem domain is generally
well-defined/constrained hence their solution domain is also
constrained. More often than not, extensibility and poly-morphism is
not an issue in the contexts. And in general, this is what the
developer is looking for...
Components almost by definition need to interoperate with each other
dynamically. In designing these libraries, the struggle is generally
between extensibility and simplicity. Simplicity promotes useability
(and the high levels of abstraction). Extensibility promotes
RE-useability (and virtually implies low levels of abstraction).
Unfortunately, these goals tend to be mutually exclusive.
>
> I believe the acceptance of software components is very much like the
> acceptance of components in other areas and is mainly a matter of culture.
> It has two prerequisites:
> (a) the general agrement of the nature of particular application
> domains. At some stage, a common way of doing it is established and people
> who thoughtdifferently abandon their previous ways.
> (b) the agreement upon standards.
> Where everyone agrees upon how certainthings are done and about the measures
> and sizes of the other parts they have to be attached to, then a component
> industry may grow in that field. The problems that you complain of may
> testify of either an immature attempt (everyone has not yet agreed about the
> nature of the domain in the first place) or an attempt at standartization at
> the wrong place. Since this is a slow cutlural process, there is no way to
> say if a particlar attempts will succeeds and who's standard-draft will win.
I find the assumption that the problem domains are standardized as you
describe as rather implausible. Historically, software standards that
arise are generally defacto -- they are not reached via general
agreement but rather by political/financial coercion. Microsoft's
Direct3D, case in point.
This brings up an example. Microsoft is currently working with SGI to
develop Fahrenheit -- basically, a COM-ified version of SGI's Inventor
with a few more bells and whistles. Inventor was/is a well-designed,
standardized component (sort of, anyway) library. Even so, it was
sparsely used mostly because it's performance characteristics were not
acceptable for anything but trivial rendering applications.
Tim Ottinger
aren't implementations, they're the means by which to build
implementations.
That's why we have /Adapter/ (GoF). :-)
Tim
Tony
> Tony wrote:
> It seems to me that you have somewhat idealistic expectations of
> component-level reuse.
Yeppers (but not so "idealistic" in my own shop).
> In my experience, the results of component-level reuse has been mostly a
> wash.
It's still early. Expect more soon though.
> I do not know of a single commercially-distributed component
> library that has been heralded as particularly well-designed by anyone
> other than the people that designed it.
>
> More often than not, the problem with component libraries is that they
> generally are designed with the lowest common denominator in mind.
> Why? Because that's the problem domain where the solution is most
> tractable. When you try to extend the design beyond that level,
<snip>
OK, but the point (the ideal) is finished product not product evolution.
Product that MEETS the specification and doesn't need to be tailored
beyond the configuration settings. I can see potential end-user
frustration for early adopters when the components are still immature.
> Having said that, I find it odd that you should find components a more
> important technology than the design process that goes into them.
Again, I don't believe there is that much wrong with existing practice.
> You
> say yourself that someday "we will be designing component-based
> systems". Just where do you expect these wonderfully reuseable
> components to come from? And what makes you think that patterns won't
> play a significant role in the usage of those components?
"Patterns" as a specification? I don't think so, but I'm sure some will
be able to be had that way. The component sales/marketing vehicles
aren't that different then the way packaged software is sold today. You
may think that "Visitor" is a good marketing name for a component, but I
do not.
> COM and
> CORBA, the two most common component architecture paradigms, by their
> very definitions imply the use of patterns.
Well evolving ones they are anyway (but I have faith that the longer
they're "in committee" the more useless they will become). You could
also say that ANY software implies the use of "patterns". So what?
Every object has a "pattern". So what?
Having a toolbox of designs and mechanisms is good. What you call them
isn't that important.
Tony
avne...@netvision.net.il says...
> I believe the acceptance of software components is very much like the
> acceptance of components in other areas and is mainly a matter of culture.
> It has two prerequisites:
> (a) the general agrement of the nature of particular application
> domains. At some stage, a common way of doing it is established and people
> who thoughtdifferently abandon their previous ways.
> (b) the agreement upon standards.
> Where everyone agrees upon how certainthings are done and about the measures
> and sizes of the other parts they have to be attached to, then a component
> industry may grow in that field. The problems that you complain of may
> testify of either an immature attempt (everyone has not yet agreed about the
> nature of the domain in the first place) or an attempt at standartization at
> the wrong place. Since this is a slow cutlural process, there is no way to
> say if a particlar attempts will succeeds and who's standard-draft will win.
You forgot to add that self-serving vendors will actually undermine
what's good for the industry to create their own wealth. (No, I won't
name names but every I'm sure can name of few of their own). Indeed, the
IT industry (and others using IT) has greatly been held back by
introduction of vendor standards where industry standards would be more
appropriate.
Tony
But look a little farther ahead. Flight has been harnessed e.g. It's no
longer a frontier. The next step, space-planes, aren't necessary so we
probably won't go there other than as an excercise or niche. Sure you
can make minor improvements to planes and such, but the frontier is
really closed. Similarly there will be ends for the IT frontier. My
prediction is that it won't be pretty if there are lots-o-people that
just know how to program. This having witnessed other skilled trades
become obsolete to automation (robots). Some will find new work. Some
won't have enough heart left for another career change.
Programming: a career?
John Goodsen
have any ideas. The topic is what I call Component Interface
Synthesis.
Let's say I'm maintaining 3 models: conceptual, specification and
implementation. The conceptual model is just that - purely
conceptual. It is used to communicate with users and customers.
The specification model identifies external interfaces and component
interfaces that exist in the high level design. The implementation
model models the underlying implementation of interfaces from
the specification model. Somewhere between the specification
and interface models, we make choices to use an off-the-shelf
component or build a custom component in our design.
It seems to me that in our decision process to buy-or-build
a component, we need to evaluate how a pre-existing component's
interface is compatible with our specification. Of course, they
are rarely the same, so there may be a process of "synthesis"
where we might rework our API to support a reusable component,
or (more likely) we will create an adapter that lets us "plug" in
an off-the shelf component and adhere to the interface we defined
in the specification model.
My questions:
- Has anyone done something similar to this in their design process?
- If you have, is Component Interface Synthesis a proper term for this
process.
thanks in advance,
--
John Goodsen RADSoft / Training, Mentoring and Consulting in:
jgoo...@radsoft.com - UML modeling and OOA/D principles
http://www.radsoft.com - Use Centered Object-Oriented Design
602.283.0142 - Rapid Incremental S/W Delivery Process
"Example isn't another way to teach, it is the only way to teach. "
- Albert Einstein
--
John Goodsen RADSoft / Training, Mentoring and Consulting in:
jgoo...@radsoft.com - UML modeling and OOA/D principles
http://www.radsoft.com - Use Centered Object-Oriented Design
602.283.0142 - Rapid Incremental S/W Delivery Process
"Example isn't another way to teach, it is the only way to teach. "
- Albert Einstein
Tony wrote in message ...