Prev: OOD and Normalisation
Next: Newbie question about OO database structure & programming
From: v4vijayakumar on 3 May 2007 05:55
Can all design issues boil down to these 23 (GoF) design pattern
solutions?

(Even some of these design pattern looks same. For example,

1. "Factory method" differs object creation to subclasses; "Template
method" differs algorithm implementation to its subclasses

2. "Builder" makes construction reusable; "Mediator" makes
interaction reusable)

From: Laurent Deniau on 3 May 2007 06:03
v4vijayakumar wrote:
> Can all design issues boil down to these 23 (GoF) design pattern
> solutions?

These 23 design patterns are not the solutions to all the design issues.
Moreover, they are related to the particular context of object-oriented
programming with static typing.

> (Even some of these design pattern looks same. For example,
>
> 1. "Factory method" differs object creation to subclasses; "Template
> method" differs algorithm implementation to its subclasses
>
> 2. "Builder" makes construction reusable; "Mediator" makes
> interaction reusable)

a+, ld.
From: v4vijayakumar on 3 May 2007 08:23
On May 3, 3:03 pm, Laurent Deniau <laurent.den...(a)cern.ch> wrote:
> v4vijayakumar wrote:
> > Can all design issues boil down to these 23 (GoF) design pattern
> > solutions?
>
> These 23 design patterns are not the solutions to all the design issues.
> Moreover, they are related to the particular context of object-oriented
> programming with static typing.
>
....
Are there any classifications other than creation, structural and
behavioral?

From: Laurent Deniau on 3 May 2007 08:45
v4vijayakumar wrote:
> On May 3, 3:03 pm, Laurent Deniau <laurent.den...(a)cern.ch> wrote:
>> v4vijayakumar wrote:
>>> Can all design issues boil down to these 23 (GoF) design pattern
>>> solutions?
>> These 23 design patterns are not the solutions to all the design issues.
>> Moreover, they are related to the particular context of object-oriented
>> programming with static typing.
>>
> ...
> Are there any classifications other than creation, structural and
> behavioral?

- Dynamic patterns which are nearly orthogonal to the ones you cite
since they are related to object-oriented programming with dynamic
typing and dynamic dispatch and offer a very different approach to OOP.

- Dynamic behavioral patterns which are an extension of the behavioral
patterns to introduce some dynamic into static typed languages. See also
adaptive object model or executable design patterns.

- Concurrency patterns which are related to concurrent access problems.

Otherwise, the other group is architectural patterns which address the
problem related to software architecture, which can be seen as part of
the design, but are usually of higher level like the MVC. They also
relies more on dynamic (behavioral) patterns since those have been
developed to solve the architectural problems.

a+, ld.
From: H. S. Lahman on 3 May 2007 15:16
Responding to V4vijayakumar...

> Can all design issues boil down to these 23 (GoF) design pattern
> solutions?

No. Those happen to deal with some of the more common design situations.
But there are a flock of books out now on design patterns that cover
lots of other situations.

> (Even some of these design pattern looks same. For example,

That's mainly because almost all of the Gof patterns employ some
combination of the same two techniques: delegation and polymorphic
dispatch. In addition, most of the patterns are focused on a single very
basic problem: where behavior must be substituted based on dynamic
context and that substitution is too complex to capture in a simple
static association between a client and some service.

> 1. "Factory method" differs object creation to subclasses; "Template
> method" differs algorithm implementation to its subclasses

I think they are substantially different. Factory Method involves a
single generalization while Template requires a 1:1 mapping between
subclasses of two generalizations.

> 2. "Builder" makes construction reusable; "Mediator" makes
> interaction reusable)

I agree these are pretty close but I think there are still substantial
differences. In Mediator the ConcreteMediator coordinates activities
among two or more ConcreteColleagues. IOW, the coordination rules among
Colleagues are "hard-wired" in ConcreteMediator's implementation. In
Builder, basically all one has is an iteration in Director over invoking
ConcretBuilders and each ConcreteBuilder operates autonomously. IOW,
Director doesn't need to know very much about Builders and does not have
to coordinate any of their collaborations.

--

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



 |  Next  |  Last
Pages: 1 2
Prev: OOD and Normalisation
Next: Newbie question about OO database structure & programming