From: Ashley Sheridan on
On Wed, 2009-12-30 at 16:50 +0000, Tony Marston wrote:

> I have recently been engaged in an argument via email with someone who
> criticises my low opinion of design patterns (refer to
> http://www.tonymarston.net/php-mysql/design-patterns.html ). He says that
> design patterns are merely a convention and not a reusable component. My
> argument is that something called a pattern is supposed to have a recurring
> theme, some element of reusability, so that all subsequent implementations
> of a pattern should require less effort than the first implementation. If
> design patterns do not provide any reusable code then what is the point of
> using them?
>
>
>
> I do not use design patterns as I consider them to be the wrong level of
> abstraction. I am in the business of designing and developing entire
> applications which comprise of numerous application transactions, so I much
> prefer to use transaction patterns (refer to
> http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html and
> http://www.tonymarston.net/php-mysql/transaction-patterns.html ) as these
> provide large amounts of reusable code and are therefore a significant aid
> to programmer productivity.
>
>
>
> What is your opinion? Are design patterns supposed to provide reusable code
> or not? If not, and each implementation of a pattern takes just as much time
> as the first, then where are the productivity gains from using design
> patterns?
>
>
> --
> Tony Marston
> http://www.tonymarston.net
> http://www.radicore.org
>
>
>


In my opinion, patterns primarily aid development of systems where more
than one person will be working on it, or where more people may need to
refer to the code in the future as a basis for something else.

Programming essentially is about not reinventing the wheel all the time,
by reusing ideas either as they stand, or as a base for improving upon.
To an extent, I think every programmer uses design patterns, it's just a
matter of how complex a pattern one uses, and how closely one stays to
the original pattern.

Thanks,
Ash
http://www.ashleysheridan.co.uk


From: tedd on
At 4:50 PM +0000 12/30/09, Tony Marston wrote:
>What is your opinion? Are design patterns supposed to provide reusable code
>or not? If not, and each implementation of a pattern takes just as much time
>as the first, then where are the productivity gains from using design
>patterns?
>
>--
>Tony Marston

Tony:

I don't think reusable code is the main point of "Design Patterns".
From what I've read, "Design Patterns" are more of a "If you are
faced with this problem, here's a solution" kind of thing. Reusable
code is more a by-product of the process.

Instead "Design Patterns" are more about identifying and classifying
common problems than reusable code. The point is if you can define
your problem as a category referenced by "Design Patterns", then you
are closer to solving it.

With that said, I find "Design Patterns" frustrating because of the
level of abstraction most authors use to identify the
problem/solution pair. Instead of showing a real world example, their
solution are so broad, so encompassing, so abstract, that they lose
me.

However, I must admit that the newer ways of doing things are
bringing to the table ways to do things that were not possible
before. So, in the end we all have to keep learning just to keep up.
As I've said many times before "I've learned something new every day
of my life -- and I'm getting damned tried of it."

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
From: Paul M Foster on
On Wed, Dec 30, 2009 at 04:50:40PM -0000, Tony Marston wrote:

> I have recently been engaged in an argument via email with someone who
> criticises my low opinion of design patterns (refer to
> http://www.tonymarston.net/php-mysql/design-patterns.html ). He says that
> design patterns are merely a convention and not a reusable component. My
> argument is that something called a pattern is supposed to have a recurring
> theme, some element of reusability, so that all subsequent implementations
> of a pattern should require less effort than the first implementation. If
> design patterns do not provide any reusable code then what is the point of
> using them?
>

There's a weird terminology problem here. A "design pattern" is just an
idea. Once you implement it, it can become a source of reusable code.

>
>
> I do not use design patterns as I consider them to be the wrong level of
> abstraction. I am in the business of designing and developing entire
> applications which comprise of numerous application transactions, so I much
> prefer to use transaction patterns (refer to
> http://www.tonymarston.net/php-mysql/design-patterns-are-dead.html and
> http://www.tonymarston.net/php-mysql/transaction-patterns.html ) as these
> provide large amounts of reusable code and are therefore a significant aid
> to programmer productivity.
>
>
>
> What is your opinion? Are design patterns supposed to provide reusable code
> or not? If not, and each implementation of a pattern takes just as much time
> as the first, then where are the productivity gains from using design
> patterns?
>

It depends on how you implement it. You can prevent it from being
reusable by implementing it in such a way that there's just no way to
adapt it to different circumstances.

But for the most part, it's like any other code you expect to reuse,
whether it's just a function, a plain class or whatever. If you
implement it properly, it will be reusable elsewhere.

Paul

--
Paul M. Foster
From: tedd on
At 5:16 PM +0000 1/3/10, Tony Marston wrote:
>
>I offer an alternative view - there are those programmers who need design
>patterns to fill a hole in their experience, as a sort of mental crutch, and
>there are those who do not need design patterns as they have the experience
>and ability to work without them, just as an experienced cyclist does not
>need training wheels, and an experienced artist does not need a
>painting-by-numbers kit.
>
>--
>Tony Marston

Tony:

I respect your opinion, but there may be more to this than what you said.

As some of you know, I've been pounding code since 1965 and while I'm
not the sharpest crayon in the box, I am seeing new things all the
time. Perhaps I'm seeing the same thing over and over, but while some
of this is rehashing old ideas and presenting them in new packaging,
some of it is actually new concepts worth investigating.

Clearly OOP is different than procedural code. Likewise, Design
Patterns (DP) are different ways to categorize problem solving than
relying upon personal experience. These two new camps (OOP/DP) are
similar in grouping as are the older procedural and experience camps,
if you get my meaning. These different camps are much like a light
switch, either you swing one way or the other, but not usually both.

I find myself in both camps and being somewhat overwhelmed by the
newer camp. The procedural/experience camp provides me with all the
tools I need to get anything done that I want done. Whereas, the
OOP/DP provides me with enough intrigue to prompt me to investigate
-- and the more I look, the better I like. There appears to be more
here than just an inexperience issue.

Cheers,

tedd

--
-------
http://sperling.com http://ancientstones.com http://earthstones.com