Collecting Parameter Design Pattern?

[Andreas Thiele]

I am just reading Bruce Eckel's `Thinking in Pattern'. Before going into
detail with singleton design pattern Eckel talks about simplifying idioms.
He presents Messenger and - more general - Collecting Parameter but doesn't
explicitely call them design pattern.

I wonder if these two should be considered design pattern?

From my naive point of view I'd say, they just describe what OO is all
about.

Andreas

 

[Stefan Ram]

From my naive point of view I'd say, they just describe what OO
is all about.

(The relation of your question to Java is not obvious, since
you do not mention Java. There also is "comp.object".)

OO to me is essentially
- run-time polymorphism
- "everything" that could possibly be an object is an
object, not only numbers ("2"), but also blocks
of code ("{ f(2); }").

I just looked at "Messenger" and "Collecting Parameter"; and
it seems to me as if this could be useful in any procedural
language, like C, too. Why does it describe what "OO" is
all about?

 

[Andreas Thiele]

(The relation of your question to Java is not obvious, since
you do not mention Java. There also is "comp.object".)

Thinking in Pattern explains OO design pattern using Java and currently I'm
learning Java so I thought this might be the right group

OO to me is essentially
- run-time polymorphism
- "everything" that could possibly be an object is an
object, not only numbers ("2"), but also blocks
of code ("{ f(2); }").

I just looked at "Messenger" and "Collecting Parameter"; and
it seems to me as if this could be useful in any procedural
language, like C, too. Why does it describe what "OO" is
all about?

I thought OO basically is binding function and state. Objects are made to
represent real world objects. So the most natural way to use objects is to
capture state in their member variables. Furthermore I'd not consider it
remarkable to pass them around. So Messenger and Collecting Parameter is
nothing fancy.

Having a look into my german edition of Gamma's Design Pattern doesn't
reveal anything related to those two. So, to answer my own question, I think
they are not really design pattern. This seems to be the reason Eckel
doesn't explicitely call them pattern. I think he just wants to emphasise
that you can introduce idioms to the core language by using OO.

Right?
Did you find any other infos?

Andreas

 

[Stefan Ram]

I thought OO basically is binding function and state.

There are different points of view. One can only agree
that there is not a single definition accepted by everyone.
I have a German language page [1] giving two definition
by relevant sources, in English: [2] and [3], see also [4].

Having a look into my german edition of Gamma's Design Pattern doesn't
reveal anything related to those two. So, to answer my own question, I think
they are not really design pattern.

Here are three quotations regarding software design patterns:

From: Pascal Costanza <[email protected]>
Newsgroups: comp.lang.lisp
Message-ID: <[email protected]>

The Design Patterns book has a subtext that strongly suggests that
patterns must be complex, must use some kind of UML notation and must
have something to do with OOP. Nothing of this is true. Here is an
example of a set of patterns that are quite different:
http://c2.com/cgi/wiki?SimplyUnderstoodCode (written by Richard Gabriel
specifically to show that there is more to patterns than people usually
think).

From: Matthew Danish <[email protected]>
Newsgroups: comp.lang.lisp
Message-ID: <[email protected]>

Hah, you just opened up another can of worms! =) Design patterns as
realized in software architecture today are bull; they are just
published and accepted ways of working around the limitations of C++
and Java. There is nothing fundamental about most of them that makes
them transcend language. Especially since the paradigms of different
languages really do encourage different solutions to the same problem.

From: Stefan Matthias Aust <[email protected]>
Newsgroups: de.comp.lang.java
Message-ID: <[email protected]>

[[ Translation to English follows below! ]]

Schon richtig. Aber Basis für das Buch war IIRC seine Doktorarbeit -
und die war in Deutsch. Die Idee der Patterns gab es ja schon vorher,
siehe Portland-Pattern-Repository, maßgeblich bestimmt von Kent Beck
(Smalltalk) und Richard P. Gabriel (Lisp), ursprünglich erfunden von
Christopher Alexander (Architekt). Aber Gammas Leistung war das
Formalisieren von Basispatterns für C++ (und die Beschreibung eines
Anwendungsrahmenwerks damit).

in English:

Quite right. But the basis of his book was his doctorate -
and that was written in German language. The idea of patterns was there already before,
see the Portland-Pattern-Repository, significantly affected by Kent Beck
(Smalltalk) and Richard P. Gabriel (Lisp), originally invented by
Christopher Alexander (architect). But Gammas merit was the
formalization of basic patterns for C++ (and the description of an
application framework using them).

[1]
http://www.purl.org/stefan_ram/pub/begriff_objektorientierte_programmierung_de

[2]
http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

[3]
http://www.ncits.org/tc_home/k5htm/o1.htm#object-oriented

[4]
http://c2.com/cgi/wiki?ObjectOrientedProgramming

 

[Andreas Thiele]

...
[quite a lot of text]
...

Thanks for your great pointers.

Well, it has not been the OPs intend to open a can of worms (or start a
flame war ) ).

Nevertheless I was especially amused about Kays statement:
"OOP to me means only messaging, local retention and protection and hiding
of state-process, and extreme late-binding of all things. It can be done in
Smalltalk and in LISP. There are possibly other systems in which this is
possible, but I'm not aware of them."

Whereas probably my new employers technical director (strong emphasis on
Java and Design Pattern) might not be as amused as I am. So I decided
understanding pattern within the Java context might be a more appreciated
approach )

I am aware, that `Design Pattern' are dependent on the language at hands as
Norvig pointed out in:
http://www.norvig.com/design-patterns/ppframe.htm
and I would love to have a complete description of `Gamma's' 23 pattern in
Common Lisp, which I haven't found yet. But, after in depth understanding
these pattern, maybe I can provide such a compilation.

Meanwhile I have to fulfill the task of learning Java - really!

Andreas

 

[Stefan Ram]

and I would love to have a complete description of `Gamma's' 23 pattern in
Common Lisp, which I haven't found yet. But, after in depth understanding
these pattern, maybe I can provide such a compilation.

The "visitor pattern" is a complicated means to emulate
dynamic multi-dispatch for two arguments at runtime (where the
method implementing an operation depends on the run-time type
of all arguments). In Common Lisp, AFAIK, this is already
being handled by the language (by the CLOS), so there is no
need for such a pattern in Lisp.

On the other hand, possibly, there is a need for other
patterns in Lisp, that does not occur with Java.

So, it won't be a 1-to-1-translation, some patterns will have
to be removed and possibly others will have to be added.

 

[Chris Uppal]

I am just reading Bruce Eckel's `Thinking in Pattern'. Before going into
detail with singleton design pattern Eckel talks about simplifying idioms.
He presents Messenger and - more general - Collecting Parameter but
doesn't explicitely call them design pattern.

I wonder if these two should be considered design pattern?

I don't think there's much difference between an idiom and a design pattern. A
design pattern is nothing more than an idiom with a name. Someone must have
felt that the idiom was sufficiently important/useful/common that it deserved a
name (so that designers can talk about using it more easily). If thereafter
enough people find that name useful, then they'll start using it. At that
point the idiom has a name that is known to the (or a) community, and can
reasonably be called a pattern.

That's all.

If you find yourself talking about using Messenger to simplify some code (i.e.
using the word "messenger" instead of spelling out what steps you'd take
explicitly), or if you find you colleagues doing so, then (at least in your
community) that way of organising code has become a design pattern.

-- chris

 

[Thomas Weidenfeller]

I don't think there's much difference between an idiom and a design pattern.

There is a significant difference between the meaning of the two terms:

Idioms are language-specific, small and each one stands-alone. Patterns
are generalized solutions to common problems (in a certain field). When
a set of patterns connect and relate you have a pattern language.

A particular pattern language might be widely known (GoF), or just
limited to a few insiders.

A
design pattern is nothing more than an idiom with a name.

Nop, idioms also have names. E.g. a common Java idiom is 'Return
immutables from getters'. See, it has a name. It is language specific -
you won't care about it in C or C++ (you would do it with const), and
you can't generalize it.

Someone must have
felt that the idiom was sufficiently important/useful/common that it deserved a
name (so that designers can talk about using it more easily). If thereafter
enough people find that name useful, then they'll start using it. At that
point the idiom has a name that is known to the (or a) community, and can
reasonably be called a pattern.

The process should be slightly different. You figure out that your idiom
exists in other languages, too. That you can formalize it
language-independent, and that it fixes a common problem. Example:

'First time in'. You initialize some data prior to the first time you
need it:

long seed = 0;
public doSomething() {
if(seed == 0) {
seed = timeinMilli();
}
// do the work
}

it is small, but it is a pattern. You can find it "everywhere".

/Thomas

 

[Andreas Thiele]

...
Nop, idioms also have names. E.g. a common Java idiom is 'Return
immutables from getters'. See, it has a name. It is language specific -
you won't care about it in C or C++ (you would do it with const), and
you can't generalize it.
...

Sounds great. Is this your definition or do you have a reference to a
commonly accepted/used definition of idiom in CS?

Andreas