What's a pattern?

[Jan Paulsen]

I'm getting a bit philosophical here, please point me towards a better
newsgroup if I'm too much off-topic.

Anyway, I bet the subject got your attention. Perhaps reading on will
help justify the title.

Recently, I read a post in this newsgroup describing the "select"
technique as a pattern. In case you need a reminder, the "select"
technique is based on a statement of the same name in which you give a
number of channels and the result of the statement is the result of
reading a message from the first channel. The technique is nothing
special to Java, but can also be find e.g. in functional languages.

This led me to wonder a bit about our usage of the word "pattern", which
I would very much like your input about.

Besides the common notion of a "pattern", there are more academically
precise notions. There's the GoF book describing design patterns,
Alexander gave the origins to the paradigm in his seminal work on
architectural patterns, Lynn and Manns gave an introduction to the
personal leadership of change using patterns, we have even learned about
anti-patterns in analysis and no doubt I have forgotten some important
works.

However, it seems to me that common use, as was the case of the post
mentioned in the beginning of this article, is that almost everything is
regarded as a "pattern" if there's some repetitive nature to the
observation.

So, are we starting to use the common notion rather than the
academically precise and well-researched definitions? That is, do you
often say to your colleges that "I have this pattern in my code" where
you are not referring to a well-defined pattern, but to some custom or,
as I call it, technique? Are you, sitting in the canteen, telling about
"patterns" in your methodology when you cannot pinpoint the origin of
the pattern you are talking about? Or do you see some other uses of the
term "pattern" when it is not well-defined?

Again, sorry if I'm off-topic, just started to wonder.

Regards,
Jan Paulsen

 

[Jan Paulsen]

I'm getting a bit philosophical here, please point me towards a better
newsgroup if I'm too much off-topic.

Anyway, I bet the subject got your attention. Perhaps reading on will
help justify the title.

Recently, I read a post in this newsgroup describing the "select"
technique as a pattern. In case you need a reminder, the "select"
technique is based on a statement of the same name in which you give a
number of channels and the result of the statement is the result of
reading a message from the first channel. The technique is nothing
special to Java, but can also be find e.g. in functional languages.

This led me to wonder a bit about our usage of the word "pattern", which
I would very much like your input about.

Besides the common notion of a "pattern", there are more academically
precise notions. There's the GoF book describing design patterns,
Alexander gave the origins to the paradigm in his seminal work on
architectural patterns, Lynn and Manns gave an introduction to the
personal leadership of change using patterns, we have even learned about
anti-patterns in analysis and no doubt I have forgotten some important
works.

However, it seems to me that common use, as was the case of the post
mentioned in the beginning of this article, is that almost everything is
regarded as a "pattern" if there's some repetitive nature to the
observation.

So, are we starting to use the common notion rather than the
academically precise and well-researched definitions? That is, do you
often say to your colleges that "I have this pattern in my code" where
you are not referring to a well-defined pattern, but to some custom or,
as I call it, technique? Are you, sitting in the canteen, telling about
"patterns" in your methodology when you cannot pinpoint the origin of
the pattern you are talking about? Or do you see some other uses of the
term "pattern" when it is not well-defined?

Again, sorry if I'm off-topic, just started to wonder.

Regards,
Jan Paulsen

Of course, I got the semantics of the "select" statement wrong. The
result of the statement is reading a message from any of the channels
having a statement ready to be read. Sorry about that.

And, of course, the common use may be as good as any other use in practice.

Regards,
Jan Pualsen

 

[markspace]

However, it seems to me that common use, as was the case of the post
mentioned in the beginning of this article, is that almost everything is
regarded as a "pattern" if there's some repetitive nature to the
observation.

I believe there are specific patterns that cover less general usage. An
Iterator might be a general pattern for iterating over a set of data,
but when dealing with IO or the java.nio.channels.Selector class, there
may be specific patterns that govern their usage. Even when one is
iterating over an entire IO stream or a set of buffers returned by
java.nio.channels.Selector, the usage may still be different than the
general case of an Iterator.

Because those patterns are domain (or even smaller) specific, they don't
tend to make it into the general research literature. I think they
qualify as patterns nevertheless.

 

[Jan Paulsen]

I believe there are specific patterns that cover less general usage. An
Iterator might be a general pattern for iterating over a set of data,
but when dealing with IO or the java.nio.channels.Selector class, there
may be specific patterns that govern their usage. Even when one is
iterating over an entire IO stream or a set of buffers returned by
java.nio.channels.Selector, the usage may still be different than the
general case of an Iterator.

Because those patterns are domain (or even smaller) specific, they don't
tend to make it into the general research literature. I think they
qualify as patterns nevertheless.

Good point! I especially like the focus towards smaller domains. I guess
that the "pattern" terminology has become useful even for what I
would've called "techniques". Perhaps we're in the midst of some
important paradigm change in which techniques discovered in different
programming languages are becoming so important that we called them
"patterns"?

Regards,
Jan Paulsen

 

[markspace]

Perhaps we're in the midst of some
important paradigm change in which techniques discovered in different
programming languages are becoming so important that we called them
"patterns"?

I also think of patterns as synonymous with "best practice." Whereas to
me a "technique" might not be, or might be so very specific that it
doesn't qualify as a pattern. Just my 2 cents there.

For example, I'm currently noodling around with some fixed point
arithmetic. There are "patterns" for doing this, but the whole concept
is so specific I don't think of them as patterns. I think "techniques"
would be a better description.

Whereas a Selector is such a well understood and general concept, even
tough it's not as general as a stream or iterator, its proper uses still
qualify as a pattern.

 

[Stefan Ram]

That is, do you often say to your colleges that "I have
this pattern in my code" where you are not referring to a
well-defined pattern, but to some custom or, as I call it,
technique?

»((Software )Design )Pattern«, after all, also is just a
noun phrase made from common English words, so its meaning
derives from the meaning of these words in a regular way.

You might like to agree upon a specific term. »Named
pattern« or »Described pattern« comes to my mind, for a
pattern that has been named and described in a work
according to some convention.

~~

In the eighteenth century, there were so-called
»pattern books«, see

Heckscher, Morrison H., and Peter M. Kenny.
"English Pattern Books in Eighteenth-Century America".
In Heilbrunn Timeline of Art History.
New York: The Metropolitan Museum of Art, 2000.

http://www.metmuseum.org/toah/hd/enpb/hd_enpb.htm

(October 2003)

 

[Stefan Ram]

Of course, I got the semantics of the "select" statement wrong. The
result of the statement is reading a message from any of the channels
having a statement ready to be read. Sorry about that.

I am not aware of a "select" statement in Java.

The statements are (simplified):

the labeled statement,
the if-then statement,
the if-then-else statement,
the while statement,
the for statement,
the block,
the empty statement,
the expression statement,
the assert statement,
the switch statement,
the do statement,
the break statement,
the continue statement,
the return statement,
the synchronized statement,
the throw statement, and
the try statement.

 

[Jan Paulsen]

I am not aware of a "select" statement in Java.

The statements are (simplified):

the labeled statement,
the if-then statement,
the if-then-else statement,
the while statement,
the for statement,
the block,
the empty statement,
the expression statement,
the assert statement,
the switch statement,
the do statement,
the break statement,
the continue statement,
the return statement,
the synchronized statement,
the throw statement, and
the try statement.

Sorry, I was just quoting a posting. I am aware that there's no "select"
statement in Java. I guess the quoted posting was about
java.nio.channels.Selector. Sorry for confusing the discussion, my mind
was with functional languages.

(but, hey, we got a repetition of statements, nice)

Regards,
Jan Paulsen

 

[Roedy Green]

Anyway, I bet the subject got your attention. Perhaps reading on will
help justify the title.

A pattern is a standard solution to a class of problems, but the
solution is a little too complex to stomp out with a single class or
code generator.

People however can generate the standard solutions after having seen a
few example solutions. Humans have some magical ability to pull out
the common abstraction, even when they can't understand how they do
it, or reformulate the abstraction into concrete general purpose code.
..
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Let us pray it is not so, or if it is, that it will not become widely known."
~ Wife of the Bishop of Exeter on hearing of Darwin's theory of the common descent of humans and apes.

 

[Jan Paulsen]

I also think of patterns as synonymous with "best practice." Whereas to
me a "technique" might not be, or might be so very specific that it
doesn't qualify as a pattern. Just my 2 cents there.

For example, I'm currently noodling around with some fixed point
arithmetic. There are "patterns" for doing this, but the whole concept
is so specific I don't think of them as patterns. I think "techniques"
would be a better description.

Whereas a Selector is such a well understood and general concept, even
tough it's not as general as a stream or iterator, its proper uses still
qualify as a pattern.

I would take care of using the term "best practice". It kind of infers
something like "we're doing this because we do not want to think". A
"pattern", on the other hand, to me means that "we see this often and it
works".

But this is interesting. What you're doing in fixed point arithmetic is
hopefully theoretically sound and so would years ago have been called
"well-known techniques". Why don't we call these "patterns" for fixed
point arithmetic? I myself would not, but I am wondering...

I think the difference is in the level of abstraction. A "pattern" seems
to me to be at a higher level of abstraction than a "technique", but
both are important and useful. Just my two cents...

Regards,
Jan Paulsen

 

[Jan Paulsen]

»((Software )Design )Pattern«, after all, also is just a
noun phrase made from common English words, so its meaning
derives from the meaning of these words in a regular way.

You might like to agree upon a specific term. »Named
pattern« or »Described pattern« comes to my mind, for a
pattern that has been named and described in a work
according to some convention.

~~

In the eighteenth century, there were so-called
»pattern books«, see

Heckscher, Morrison H., and Peter M. Kenny.
"English Pattern Books in Eighteenth-Century America".
In Heilbrunn Timeline of Art History.
New York: The Metropolitan Museum of Art, 2000.

http://www.metmuseum.org/toah/hd/enpb/hd_enpb.htm

(October 2003)

True, but I do believe that current (as was the case in 18th century)
use of "patterns" in software is especially "design patterns", and I
doubt anyone would disagree that these come from the GoF book. Or am I
wrong?

Regards,
Jan Paulsen

 

[Jan Paulsen]

»((Software )Design )Pattern«, after all, also is just a
noun phrase made from common English words, so its meaning
derives from the meaning of these words in a regular way.

You might like to agree upon a specific term. »Named
pattern« or »Described pattern« comes to my mind, for a
pattern that has been named and described in a work
according to some convention.

~~

In the eighteenth century, there were so-called
»pattern books«, see

Heckscher, Morrison H., and Peter M. Kenny.
"English Pattern Books in Eighteenth-Century America".
In Heilbrunn Timeline of Art History.
New York: The Metropolitan Museum of Art, 2000.

http://www.metmuseum.org/toah/hd/enpb/hd_enpb.htm

(October 2003)

Oups, thank you indeed for the reference, historically very interesting.

Regards,
Jan Paulsen

 

[Jan Paulsen]

A pattern is a standard solution to a class of problems, but the
solution is a little too complex to stomp out with a single class or
code generator.

People however can generate the standard solutions after having seen a
few example solutions. Humans have some magical ability to pull out
the common abstraction, even when they can't understand how they do
it, or reformulate the abstraction into concrete general purpose code.
.

I completely agree. The important notion, to me, is the level of
abstraction. A "pattern" to me is as handed down by the GoF book, in
which patterns are (excuse me for the term) collaborating classes
solving a design issue. That said, I guess I have trouble calling a lot
of other things, including the Selector example, a pattern. To me, these
are part of the more general notion of a "technique". Oh dear, this is a
bit far out, I'm sorry.

And, yes, the human brain is very capable of generalisation. Took an AI
course once and boy are a bunch of neurons working together good a
classification problems. As you know, this is a simplified model of the
workings of the brain.

regards,
Jan Paulsen

 

[Wojtek]

Jan Paulsen wrote :

That is, do you often say to your colleges that "I have this pattern in my
code" where you are not referring to a well-defined pattern, but to some
custom or, as I call it, technique? Are you, sitting in the canteen, telling
about "patterns" in your methodology when you cannot pinpoint the origin of
the pattern you are talking about? Or do you see some other uses of the term
"pattern" when it is not well-defined?

Interesting.

I have a web app with about 200 pages. Each "edit/add new" and "list"
page set has the same flow of logic. Practically the only difference is
the class names, the Data object, SQL, and code to transfer information
around.

But the flow logic is identical to the point where I could write a
generator for it. So the generator creates a dozen or so classes with
only trivial name differences.

I have about 50 of these "use cases" (all for drop lists).

Is this enough to name it a pattern?

 

[Jan Paulsen]

Jan Paulsen wrote :

Interesting.

I have a web app with about 200 pages. Each "edit/add new" and "list"
page set has the same flow of logic. Practically the only difference is
the class names, the Data object, SQL, and code to transfer information
around.

But the flow logic is identical to the point where I could write a
generator for it. So the generator creates a dozen or so classes with
only trivial name differences.

I have about 50 of these "use cases" (all for drop lists).

Is this enough to name it a pattern?

Nice question! I would say "no" in the academic sense but "yes" in the
common sense. This means I would but careful to define it as a pattern
in daily use. The thing is, we need much more evidence that what you're
doing is a common scenario (I think it is). But how much do we need? Are
we able to put a specific percentage of the number of observed
applications to this? Or is some other way of setting the bar required?

(and, to make it clear, I'm absolutely sure your good use could easily
evolve into a well-defined "pattern", but not without changes to
accomodate for generalisation)

Regards,
Jan Paulsen

(who has way too much time on his hands currently, as is apparent)

 

[Jan Paulsen]

I believe it was my use of the word "pattern" that started all this. So
I'll offer my observations:

-- the word "pattern" is not well-defined, but has a clear enough
meaning for people to understand it. I could have used "technique",
"approach", "style", or any number of other words to convey the meaning,
and I think in almost every case it would have been just as understandable.

Yes, the word "pattern" comes up in the concept of the GoF "design
patterns" treatise, but that doesn't mean that's the exclusive domain
for using the word.

-- Besides that, in this particular example I would say that the
"select pattern" really is more of a pattern, because it appears in a
wide variety of APIs, each with its own specific implementation.

Even if you restrict your observations to the various socket APIs,
you've got BSD sockets, Winsock, .NET Sockets, Java Sockets, etc. all of
which use a very similar general "pattern", but none of which are
actually precisely identical in usage. But one need not restrict one's
observation to network APIs; the concept of having multiple waitable
objects which can be used in a blocking call, which will return when one
or more has satisfied the waiting condition, shows up in a number of
other areas.

Personally, I would advise you to not get so hung up over a single
word. If you understood the meaning in context, it did its job. If
not, then you can always ask for clarification. That's just inherent in
human communication.

Pete

Pete, I sincerely do hope that I did not offend you; your use of the
word "pattern" is not much different than so many others, I think. I'm
possibly a bit different in that, when I say "a pattern", I sometimes
mean a precisely defined pattern found in some (hopefully good) book.
There's a language difference here, because I use the work "pattern" to
describe one of those entities, but typically the native tongue when
describing the common term.

That said, I have to disagree just a bit with you. I agree that the GoF
book by no means exclusive rights for the term, but the word "pattern"
is, as so many words, loosely defined in common use, but has a precise
definition as well, to me, as handed down by books describing the
patterns all their gory detail with sound reflections based on research.
Call me sour, in which case I'm sorry (put in full-stops for me, please).

I'm just having too much time this evening, I know, and to be sure, I'm
not particularly hung up on the subject - and indeed agree that "if it
works, stop thinking so much about it".

And, yes, of course patterns originate from somewhere - they are
observed similar techniques, then some reflection is added to make the
techniques possibly even more generally useful and then presented as
digested information - a "pattern".

Don't want to start a fight here, I just started wondering.

Regards,
Jan Paulsen

 

[Jan Paulsen]

Pete, I sincerely do hope that I did not offend you; your use of the
word "pattern" is not much different than so many others, I think. I'm
possibly a bit different in that, when I say "a pattern", I sometimes
mean a precisely defined pattern found in some (hopefully good) book.
There's a language difference here, because I use the work "pattern" to
describe one of those entities, but typically the native tongue when
describing the common term.

That said, I have to disagree just a bit with you. I agree that the GoF
book by no means exclusive rights for the term, but the word "pattern"
is, as so many words, loosely defined in common use, but has a precise
definition as well, to me, as handed down by books describing the
patterns all their gory detail with sound reflections based on research.
Call me sour, in which case I'm sorry (put in full-stops for me, please).

I'm just having too much time this evening, I know, and to be sure, I'm
not particularly hung up on the subject - and indeed agree that "if it
works, stop thinking so much about it".

And, yes, of course patterns originate from somewhere - they are
observed similar techniques, then some reflection is added to make the
techniques possibly even more generally useful and then presented as
digested information - a "pattern".

Don't want to start a fight here, I just started wondering.

Regards,
Jan Paulsen

I should probably add that, yes, I am aware the the "select"
pattern/technique/whatever creeps up in various places and, yes, it is
being used as a description for how to "wait for something from a number
of channels". I have a background in functional programming, in which
this is called "channels" and one of those things simply presents
"messages". I guess this is a very general communication paradigm,
applicable to whatever, such as I/O and processes delivering results.

Regards,
Jan Paulsen

 

[Lew]

True, but I do believe that current (as was the case in 18th century)
use of "patterns" in software is especially "design patterns", and I
doubt anyone would disagree that these come from the GoF book. Or am I
wrong?

I disagree. The GoF borrowed the terminology and the format for their
"pattern language" from other domains. Many other sources besides GoF
have published design patterns. They hardly have a monopoly on the
term, the format, the concept or the usage.

It suffices to use just the English definition for "pattern".
<http://en.wiktionary.org/wiki/pattern>

 

[Jan Paulsen]

I completely agree. The important notion, to me, is the level of
abstraction. A "pattern" to me is as handed down by the GoF book, in
which patterns are (excuse me for the term) collaborating classes
solving a design issue. That said, I guess I have trouble calling a lot
of other things, including the Selector example, a pattern. To me, these
are part of the more general notion of a "technique". Oh dear, this is a
bit far out, I'm sorry.

And, yes, the human brain is very capable of generalisation. Took an AI
course once and boy are a bunch of neurons working together good a
classification problems. As you know, this is a simplified model of the
workings of the brain.

regards,
Jan Paulsen

Again, I got imprecise. I shouldn't have said that a pattern is "as
handed down by the GoF book". I should have said something akin to a
well-researched term. That is, reflection and presentation has been
added after a number of observations (knowing that some may not agree
that this is sound research). In practice, however, it IS something
handed down by the GoF book because I got fed up with reading about
patterns

Regards,
Jan Paulsen
(in a strangely philosophical mood, which is rather unlike me)

 

[Jan Paulsen]

I disagree. The GoF borrowed the terminology and the format for their
"pattern language" from other domains. Many other sources besides GoF
have published design patterns. They hardly have a monopoly on the
term, the format, the concept or the usage.

It suffices to use just the English definition for "pattern".
<http://en.wiktionary.org/wiki/pattern>

Yup, but when we talk about "design patterns" during work hours, do we
not talk about ideas originating in the GoF book (and ascendants)?
People doing analysis work may in the same way talk about
"anti-patterns" as defined in the book, the authors of which I do not
remember?

Yes, agree, those guys don't have exclusive rights. But what I'm aiming
at is that there's a difference between "pattern" in the common-day
usage and "pattern" in a precise, technical usage.

Regards,
Jan Paulsen