Hi,

        Ever since I started wading out into the OOP pool, I've been constantly
coming up against "Design Patterns". Is this a OOP-unique concept /
construct, or are there design patterns for the non-OOP (structured?)
paradigm?

Thanks,
Kenneth
--

Design patterns are possible in many languages, but they work best
when there is a "template"-like facility.  The nearest thing C has
to that are macros, which are not nearly as convenient (although I
*have* used them for type-generic algorithms on occasion).
--

None I would have heard of. But even though I do code in C most of the
time, I decided to get the original book on Design Patterns by that
fabulous "gang of four", and found that although many of the ideas do
indeed center on inheritance and other OOP concepts, there's quite a
large fraction of them that make sense from a Structured Programming
point of view, too. Just replace every occurence of 'inheritance' by
usage of a finely crafted function pointer, and you'll be in the game.

Actually, quite a lot of the stuff they write points *away* from the
usual OOP view of "everything is inheritance", and towards object
containment as a frequently preferrable alternative. And that's even
easier to model in C than inheritance.

The real tie I found between OOP and Design Patterns is that both are,
at least partly, seen as ways of solving the "big projects" problem
more easily.  These days, it's considered a bad idea to do any such
big project in anything else but OOP, and thus C++. It probably never
occured to those guys that these ideas would be valid for plain old C
programs, too :-)
--

Even if all the snow were burnt, ashes would remain.
--

I think that both the question and the response miss what design
patterns are intended to be. They are supposed to be language
independent, and represent a distillation of good solutions to a
category of design problem. If you really understand a design pattern,
it might motivate you to select a particular language as being more
appropriate to implementing a solution, but at the same time you could
implement the pattern in any language - it would just be harder in some
languages than in others.

--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
--

Turn it round, I do not think they ever thought it would not be, they
just largely used (often poor) C++ source code as a mechanism to express
the ideas in code in addition to expressing it in English.

--
Francis Glassborow
See http://www.accu.org for details of The ACCU Spring Conference, 2001
(includes many regular participants to C & C++ newsgroups)
--

Francis,

        I'm not so sure that your response is correct. Take for instance the
Factory design pattern. It seems to me that this design pattern is
purely a result of having to deal with objects. It has many virtual
constructs in it whose raison d'etre is to support the OOP paradigm.
These constructs do not map to anthing in the "real" world and exist to
support the manipulation of objects in an elegant fashion. If one looks
at the problems that this design pattern attempts to solve and tried to
solve them using procedural code, a "factory" is the last metaphor that
comes to mind as a solution.

        Maybe there are design patterns that can be utilized in the procedural
world. I dont think that they are the same as the ones described in the
OO world.

Thanks,
Kenneth
--

It _is_ a solution to the problem of creating instaces of different abstract
data types, or of "things" that adhere to a common interface. This is
useful if you face polymorphism, but polymorphism need not be expressed
in an OOPL. See X toolkits for an example of polymorphism that does
not rely on the use of an OOPL.

The article you are responding to did not say that all design patterns
are useful in procedural code. OOP is not limited to OOPLs. Some design
patterns are obviously tied to concepts like "common interface", "abstract
data type", etc. This does not imply that they cannot be put to use
when working with such concepts in a non-OOPL.

Kurt

--
| Kurt Watzka                            

--