If design patterns are not supposed to produce reusable code then why use them?

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-dea d.html and
http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusablecode then why use them?

--=-7ObZ0mIg1gqGGU56vgUH
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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-dea d.html and
> http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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



--=-7ObZ0mIg1gqGGU56vgUH--

Re: If design patterns are not supposed to produce reusablecode then why use them?

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

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable

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-dea d.html and
> http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable code then why use them?

Meant to send this to the list, sorry.

---------- Forwarded Message ----------

Subject: Re: [PHP] If design patterns are not supposed to produce reusable
code then why use them?
Date: Thursday 31 December 2009
From: Larry Garfield
To: "Tony Marston"

On Wednesday 30 December 2009 10:50:40 am 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-dea d.html and
> http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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 what you're reusing. Design patterns are reusable concepts, not
reusable code. That's the key difference.

Knowledge of design patterns is like knowledge of how different food
ingredients interact. "Hm, this needs something to bring out the taste more,
so I'll add salt." You're not going to add the same salt to each dish,
obviously, but the idea is that you need something that will bring out the
taste, and there are certain spices that will bring out the existing taste of
whatever it is you put them on, such as salt.

Similarly, if you want, say, a piece of code that will connect to a database,
you want a pre-built library, not a design pattern. (There's no shortage of
those.) If, however, you want a mechanism by which you can have different
implementations of the same system, and want to swap them out without
rewriting the calling code, then what you want is the factory *pattern*.
There may not be existing code yet for whatever system you're writing.
However, once you recognize "Ah, I want a common interface with a swappable
implementation, and I want to pick the implementation at runtime based on some
arbitrarily complex logic", then you know you don't need to think through how
you go about structuring the code to do that. Instead, you look up a
description of the factory pattern and go "ah, that makes sense, and it solves
3 problems that I didn't realize I'd run into later". Then you go and
implement code that follows that pattern, and you don't have to think through
the algorithm.

Now, it is possible to make generic implementations of some patterns that you
can re-leverage. Eg, you can have a common factory interface and a way to
request a factory, which in turn will give you the implementation object you
want. The common elements of those factories you move up to a parent class,
and therefore reuse code that way. This is known as a "Factory factory", and
is in some cases very useful and in others gross over-engineering. Knowing
which is which is something you learn through experience.

--Larry Garfield

-------------------------------------------------------

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable code then why use them?

"Larry Garfield" wrote in message
news:200912311743.16759.larry@garfieldtech.com...
> Meant to send this to the list, sorry.
>
> ---------- Forwarded Message ----------
>
> Subject: Re: [PHP] If design patterns are not supposed to produce reusable
> code then why use them?
> Date: Thursday 31 December 2009
> From: Larry Garfield
> To: "Tony Marston"
>
> On Wednesday 30 December 2009 10:50:40 am 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-dea d.html and
>> http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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 what you're reusing. Design patterns are reusable concepts,
> not
> reusable code. That's the key difference.
>
> Knowledge of design patterns is like knowledge of how different food
> ingredients interact. "Hm, this needs something to bring out the taste
> more,
> so I'll add salt." You're not going to add the same salt to each dish,
> obviously, but the idea is that you need something that will bring out the
> taste, and there are certain spices that will bring out the existing taste
> of
> whatever it is you put them on, such as salt.

Food recipes are a bad analogy for design patterns. A food recipe explicitly
identifies a list of ingredients and a list of actions which are required to
produce the intended result. The design pattern equivalent of a recipe would
simply state "take a bunch of ingredients, mix them up, heat them up, serve
them up". A design pattern merely identifies the concept, not the
implementation, so where is the REAL benefit? Where is the re-usability?

> Similarly, if you want, say, a piece of code that will connect to a
> database,
> you want a pre-built library, not a design pattern. (There's no shortage
> of
> those.) If, however, you want a mechanism by which you can have different
> implementations of the same system, and want to swap them out without
> rewriting the calling code, then what you want is the factory *pattern*.
> There may not be existing code yet for whatever system you're writing.
> However, once you recognize "Ah, I want a common interface with a
> swappable
> implementation, and I want to pick the implementation at runtime based on
> some
> arbitrarily complex logic", then you know you don't need to think through
> how
> you go about structuring the code to do that. Instead, you look up a
> description of the factory pattern and go "ah, that makes sense, and it
> solves
> 3 problems that I didn't realize I'd run into later". Then you go and
> implement code that follows that pattern, and you don't have to think
> through
> the algorithm.

I would not use the factory pattern for such a thing. I have actually
written an application which can switch between database engines - MySQL,
PostgreSQL and Oracle - simply by changing a single line of code. Although I
*could* use the factory pattern, in my experience it would be overkill and
too complicated.


> Now, it is possible to make generic implementations of some patterns that
> you
> can re-leverage. Eg, you can have a common factory interface and a way to
> request a factory, which in turn will give you the implementation object
> you
> want. The common elements of those factories you move up to a parent
> class,
> and therefore reuse code that way. This is known as a "Factory factory",
> and
> is in some cases very useful and in others gross over-engineering.
> Knowing
> which is which is something you learn through experience.

The very idea of a "factory factory" fills me with nausea. I have seen
several examples and my immediate response has always been "real programmers
don't write code like that". Yet too many programmers are taught that they
MUST use design patterns, so they follow blindly without any regard for the
consequences.

Tony Marston



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable code then why use them?

On Friday 01 January 2010 05:26:48 am Tony Marston wrote:

> > It depends what you're reusing. Design patterns are reusable concepts,
> > not
> > reusable code. That's the key difference.
> >
> > Knowledge of design patterns is like knowledge of how different food
> > ingredients interact. "Hm, this needs something to bring out the taste
> > more,
> > so I'll add salt." You're not going to add the same salt to each dish,
> > obviously, but the idea is that you need something that will bring out
> > the taste, and there are certain spices that will bring out the existing
> > taste of
> > whatever it is you put them on, such as salt.
>
> Food recipes are a bad analogy for design patterns. A food recipe
> explicitly identifies a list of ingredients and a list of actions which
> are required to produce the intended result. The design pattern equivalent
> of a recipe would simply state "take a bunch of ingredients, mix them up,
> heat them up, serve them up". A design pattern merely identifies the
> concept, not the
> implementation, so where is the REAL benefit? Where is the re-usability?

Note that I did not say that design patterns are a recipe. I said they're
knowledge of how different foods interact. They're meta-knowledge that makes
you a better chef, not a faster short-order cook.

> > Similarly, if you want, say, a piece of code that will connect to a
> > database,
> > you want a pre-built library, not a design pattern. (There's no shortage
> > of
> > those.) If, however, you want a mechanism by which you can have
> > different implementations of the same system, and want to swap them out
> > without rewriting the calling code, then what you want is the factory
> > *pattern*. There may not be existing code yet for whatever system you're
> > writing. However, once you recognize "Ah, I want a common interface with
> > a swappable
> > implementation, and I want to pick the implementation at runtime based on
> > some
> > arbitrarily complex logic", then you know you don't need to think through
> > how
> > you go about structuring the code to do that. Instead, you look up a
> > description of the factory pattern and go "ah, that makes sense, and it
> > solves
> > 3 problems that I didn't realize I'd run into later". Then you go and
> > implement code that follows that pattern, and you don't have to think
> > through
> > the algorithm.
>
> I would not use the factory pattern for such a thing. I have actually
> written an application which can switch between database engines - MySQL,
> PostgreSQL and Oracle - simply by changing a single line of code. Although
> I *could* use the factory pattern, in my experience it would be overkill
> and too complicated.

Oh really? I've written such a DB abstraction system as well. (I think most
people have at some point.) Although I did not specifically go into it saying
"I will use a factory for this", in practice it really is. Some client code
says "hey, I need a DB connection, gimme!", an intermediary piece of code
figures out which DB connection you need (based on configuration data, what
servers are available, or whatever), and passes back a PDO connection object
on which you run queries. That's a factory, in a nutshell. I suspect your DB
abstraction system works on the same general principle.

Yes, you're already using common design patterns, I wager, even if you had to
"invent" them yourself.

However, by understanding it AS a factory pattern, you can explain how it
works to someone else through a common vocabulary. You can also look at your
implementation and see where it's going to be extensible and where it's not by
comparing it to similar approaches that have already been tried and vetted.

The savings is in going "oh, hey, this approach to my problem has already been
tried, and what I was going to do would have broken here, here, and here. But
by following this similar approach, I can avoid those problems and spend less
time rewriting code later".

Yes, I have in fact run into that situation myself on more than one occasion.

> The very idea of a "factory factory" fills me with nausea. I have seen
> several examples and my immediate response has always been "real
> programmers don't write code like that". Yet too many programmers are
> taught that they MUST use design patterns, so they follow blindly without
> any regard for the consequences.
>
> Tony Marston

"Real programmers" don't make jibes about what "real programmers" do out of
ignorance.

Yes, always blindly following a given design pattern for the sake of following
a design pattern is stupid. Blindly ignoring established "solved problems"
just for the sake of avoiding those pointless design patterns is just as
stupid.

Remember, code is irrelevant. You don't sell code. You sell ideas and
concepts, implemented in code. By not having to re-invent the ideas and
concepts every time, you can save a great deal of time and effort, and
potentially a great deal of code that you don't need to rewrite later from
going down a dead-end.

There's two kinds of developers: Those that understand how they're using
design patterns and those that don't understand design patterns. :-) But both
are, in practice, using them, even if some are doing so badly (either over- or
under-using them).

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable code then why use them?

"Larry Garfield" wrote in message
news:201001010553.41956.larry@garfieldtech.com...
> On Friday 01 January 2010 05:26:48 am Tony Marston wrote:
>
>> > It depends what you're reusing. Design patterns are reusable concepts,
>> > not reusable code. That's the key difference.
>> >
>> > Knowledge of design patterns is like knowledge of how different food
>> > ingredients interact. "Hm, this needs something to bring out the taste
>> > more,
>> > so I'll add salt." You're not going to add the same salt to each dish,
>> > obviously, but the idea is that you need something that will bring out
>> > the taste, and there are certain spices that will bring out the
>> > existing
>> > taste of
>> > whatever it is you put them on, such as salt.
>>
>> Food recipes are a bad analogy for design patterns. A food recipe
>> explicitly identifies a list of ingredients and a list of actions which
>> are required to produce the intended result. The design pattern
>> equivalent
>> of a recipe would simply state "take a bunch of ingredients, mix them up,
>> heat them up, serve them up". A design pattern merely identifies the
>> concept, not the
>> implementation, so where is the REAL benefit? Where is the re-usability?
>
> Note that I did not say that design patterns are a recipe. I said they're
> knowledge of how different foods interact. They're meta-knowledge that
> makes
> you a better chef, not a faster short-order cook.

Knowledge of how foods interact will not in itself make anyone a good cook.
Knowledge of design patterns will not in itself make anyone a good
programmer. It is how that knowledge is applied which makes the difference.
The problem with design patterns is that the actual implementation is left
up to the indvidual, and if the implementation is faulty the fact that a
design pattern was used is nothing more than a red herring.

>> > Similarly, if you want, say, a piece of code that will connect to a
>> > database, you want a pre-built library, not a design pattern.
>> > (There's no shortage of
>> > those.) If, however, you want a mechanism by which you can have
>> > different implementations of the same system, and want to swap them out
>> > without rewriting the calling code, then what you want is the factory
>> > *pattern*. There may not be existing code yet for whatever system
>> > you're
>> > writing. However, once you recognize "Ah, I want a common interface
>> > with
>> > a swappable implementation, and I want to pick the implementation at
>> > runtime based on some arbitrarily complex logic", then you know you
>> > don't
>> > need to think through how
>> > you go about structuring the code to do that. Instead, you look up a
>> > description of the factory pattern and go "ah, that makes sense, and it
>> > solves 3 problems that I didn't realize I'd run into later". Then you
>> > go and
>> > implement code that follows that pattern, and you don't have to think
>> > through the algorithm.

But the problem is that you DO have to think through the algorithm as a
design pattern exists just as a vague outline, a description of a possible
solution, not a workable solution that you can just plug in and go.

>> I would not use the factory pattern for such a thing. I have actually
>> written an application which can switch between database engines - MySQL,
>> PostgreSQL and Oracle - simply by changing a single line of code.
>> Although
>> I *could* use the factory pattern, in my experience it would be overkill
>> and too complicated.
>
> Oh really? I've written such a DB abstraction system as well. (I think
> most
> people have at some point.) Although I did not specifically go into it
> saying
> "I will use a factory for this", in practice it really is. Some client
> code
> says "hey, I need a DB connection, gimme!", an intermediary piece of code
> figures out which DB connection you need (based on configuration data,
> what
> servers are available, or whatever), and passes back a PDO connection
> object
> on which you run queries. That's a factory, in a nutshell. I suspect
> your DB
> abstraction system works on the same general principle.
>
> Yes, you're already using common design patterns, I wager, even if you had
> to
> "invent" them yourself.

I may be using constructs which have proved to be efficacious in my many
years of experience, but I do not look at my solutions using the vocabulary
of design patterns as the vocablary is too wishy-washy, too vague, too much
theory and too little substance.

> However, by understanding it AS a factory pattern, you can explain how it
> works to someone else through a common vocabulary. You can also look at
> your
> implementation and see where it's going to be extensible and where it's
> not by
> comparing it to similar approaches that have already been tried and
> vetted.
>
> The savings is in going "oh, hey, this approach to my problem has already
> been
> tried, and what I was going to do would have broken here, here, and here.
> But
> by following this similar approach, I can avoid those problems and spend
> less
> time rewriting code later".
>
> Yes, I have in fact run into that situation myself on more than one
> occasion.
>
>> The very idea of a "factory factory" fills me with nausea. I have seen
>> several examples and my immediate response has always been "real
>> programmers don't write code like that". Yet too many programmers are
>> taught that they MUST use design patterns, so they follow blindly
>> without
>> any regard for the consequences.
>>
>> Tony Marston
>
> "Real programmers" don't make jibes about what "real programmers" do out
> of
> ignorance.

The why is it that my critics always say that "real programmers use design
patterns" and that if I don't then I cannot be a "real" programmer?

> Yes, always blindly following a given design pattern for the sake of
> following
> a design pattern is stupid. Blindly ignoring established "solved
> problems"
> just for the sake of avoiding those pointless design patterns is just as
> stupid.

But design patterns do not provide workable solutions, they provide outlines
for possible solutions which you then have to build yourself.

> Remember, code is irrelevant. You don't sell code. You sell ideas and
> concepts, implemented in code.

But surely if the implememnation is bad then the concepts are irrelevant.
Just because an application has been designed using all the "correct" OO
concepts and built using every design pattern ever conceived does not mean
that it will be a success. I was actually involved in a system just like
that, and I can report that it was a total disaster. It may have been used
all the right buzzwords, but it was still crap.

> By not having to re-invent the ideas and
> concepts every time, you can save a great deal of time and effort, and
> potentially a great deal of code that you don't need to rewrite later from
> going down a dead-end.

But if you have to spend time researching which pattern (or combination of
patterns) sounds like that it may be a match for your current problem, then
you have to build the code yourself from scratch, where exactly is the
saving? An experienced programmer does not need to know the name of the
pattern he is implementing in order to write good code. Just because an
inexperienced programmer does know the name of a design pattern does not
mean that his implementation will be correct.

> There's two kinds of developers: Those that understand how they're using
> design patterns and those that don't understand design patterns. :-) But
> both
> are, in practice, using them, even if some are doing so badly (either
> over- or
> under-using them).
>
> --Larry Garfield

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
http://www.tonymarston.net
http://www.radicore.org



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusablecode then why use them?

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

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable

I think it also to some extent comes down to having a shared
vocabulary. Pretty much the same way that you know which technique I'm
talking about when I use the word "recursion", which algorithm I'm
talking about when I say "quick sort" and which data structure I mean
when I say "linked list". It's way easier saying "quick sort" than
describing how the algorithms works each time. Yes, you may be able to
come up with a sorting algorithm yourself, but now when I tell you
that there is a sorting algorithm called quick sort you'll either know
which particular sorting algorithm I'm talking about, or you can go
look it up. Various implementations may for instance then employ
different sorts of optimizations to make it work well in one
particular scenario.

Design patterns are called patterns specifically because they are
things that happen to occur frequently in code, i.e. they are
recognizable patterns. It makes sense giving names to such things, and
they exist whether or not you name them of course.

There are a couple of reasons why a design pattern needn't necessarily
yield reusable *code*:
1) They transcend programming languages. A pattern may be implemented
in PHP, Python, Java, C++ or some other language, but particularly how
you would do it depends on which features and language constructs that
are available in the particular language.
2) A particular pattern may be applied to different problems. How you
would apply it depends on the nature of the problem. If we just use
the strategy pattern as an example, you may have different strategies
for an AI in a computer game, you may have different payment
strategies in an online shop and you may have different strategies for
calculating employees' salary. All of these three things are very
different in nature, but they may still use the same an overall shared
pattern that is then called "a strategy".

Tony, I disagree with your notion about design patterns being "mental
crutches". Besides for educational purposes, I see no reason why you
would want to spend time on rediscovering something that someone else
already discovered a long time ago. The point is of course not that
each time you need to do something you'll scour books and various
forms of online resources for a design pattern that fits exactly your
needs. The point is that by knowing these patterns, you'll know that
for a particular problem this particular solution tends to work well.
Indeed as you become more experienced, this will become more
transparent and "automated" so to speak.

You may very well discover or come up with some sort of pattern
yourself (though you might not necessarily give it a name), and you
may even unknowingly do something often that other people call a
design pattern and have given a name. Again, this is exactly the
reason why we call them patterns: they are things that people tend to
come up with, and they tend to work pretty well.

Now because there exists a sort of standard nomenclature, when someone
asks me how they should approach a particular problem I can tell them
to look up a particular pattern instead of trying to (re)explain it
when someone else has already done that in great detail.

I'm sure you can appreciate the benefit of having a shared vocabulary.
It's something that's going on in not just programming, but
practically in every field that exists.

I hope this makes some sense. It's my take on this anyway.

--
Daniel Egeberg

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable

2009/12/30 Tony Marston :
> 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-dea d.html and
> http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Hello Tony and everyone else (is it too late to say Happy New Year and
back to work?).

I think there seems to be a bit of a chicken and egg issue with your
comments of design patterns.

Design patterns are not blue-sky, out-of-the-box, (insert some other
marketing-speak here) concepts.

They are standardized descriptions of the purpose of code commonly seem.

They are not blocks of code to be reused.

They are nothing to do with code reuse per se.

They are to show you that the there are ways of standardizing your
approach to a problem based upon others experience. They are there to
act as templates for how you should be thinking.

Do they make you a better programmer? That depends. Do you have to
play with others? Is it easier to say we use the MVC, Active Record,
Registry and Factory Patterns? If the other members of your team do
NOT know these terms, then it is easy enough to read about them and
learn what they are for and then see how they've been implemented.
They give a common base.

Consider the alternative. I used to work on ICL System 25 running dmfx
with a 4GL style language which was converted to C before compilation
(and for the life of me I can't remember its name - it was over 20
years ago!).

The code I had to maintain was written by developers who used to write
in assembler macros. That whole argument about goto in modern
languages ... well, let's just say that THAT argument certainly didn't
exist for them.

The name that I heard for this style of coding was called "ladder
logic". No structure or common style that a newbie like me could see.

New programs were bastardised from old programs. Not cleanly, just
cobbled and a few goto's thrown in to bypass the unrequired bits. Why?
Cause only the original programmer knew what was going on and they'd
died a decade ago. Literally!

Jump forward through procedural and OOP and maybe AOP.

We all learn from the previous generation ("standing on the shoulders
of giants"). So. If they'd used design patterns back when I started
out, I'd've been able to understand the code better and faster.

I'd probably take just as long to write it, but I'd've been able to
describe it clearer and easier.

Design patterns are tools to help solve a problem. The solution MAY
involve some coding.

If you follow a design pattern, then others will be able to follow your code.

Design patterns are for community development. And probably for the
non-developer interviewers who want to see if the dweeb sat in front
of them knows his (reading from script) "Active Record" from his
(reading from script again) "Active Record" (No, sorry, just said
that, ...) "MVC" (wasn't that a chain of music shops in the UK?)...

Having said that, a real programmer only knows not to use Pascal!
Pretty much everything else is up for grabs.

Regards,

Richard.

P.S. I know nothing.

--
-----
Richard Quadling
"Standing on the shoulders of some very clever giants!"
EE : http://www.experts-exchange.com/M_248814.html
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
ZOPA : http://uk.zopa.com/member/RQuadling

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable code then why use them?

Richard Quadling wrote:
> 2009/12/30 Tony Marston :
>> 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,

Design patterns re-use the approach to solving a particular problem set.
Note that I said approach, because the code may not be re-usable, but
the tenets of the solution are embodied by the pattern regardless of the
language used. In this way, design patterns are indeed re-usable. When
you see that a particular problem falls within the domain of a Design
Pattern, then the implementation is straightforward since you can use
the design pattern to guide your implementation.

>> 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?

Each subsequent use of a design pattern should indeed require less
effort. As you absorb fully the pattern, it becomes easier and easier to
see how problems fit within one pattern or another or multiple
patterns. Having at that point already implemented solutions using
design patterns, it should become easier each time you create a solution
using a previously used design pattern.

>> 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-dea d.html and
>> http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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?

If I ask you to classify bugs by genus, does it not become easier and
easier to classify any given bug based on your previous experience of
knowing what constitutes membership in a particular genus? The same is
true of design patterns.

Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: If design patterns are not supposed to produce reusable

--0016e6d99ed5d155d2047c6fd534
Content-Type: text/plain; charset=ISO-8859-1

A pattern is simply a device used to skip out on costly dollars (as opposed
to cheap dollars). Software development is a low loyalties field. When new
workers come in and old ones are laid off, or when the project is complete
and you will likely not be working on the project again in the future,
design patterns can be useful. Loosely stepping withing the confines of a
pattern can be of great benefit (as well as safe a ton of documentation - if
you like leaving assumptions - the mortal enemy of the programmer.).

There are times when I look over project and can pick out a simple, or
sometimes simply anal, programmer. Forcing square pegs into round holes,
and round holes into diamond pegs. If you are lost on that, you know the
feeling I get when I try to understand why someone would subject their logic
solely to the pattern. Like any other system, there needs to be room for
well documented deviations.

This being said, I am a fan of transactional patterns. A program is like a
city. While structure is important, the "transactions" amongst it's
denizens are the focus. While the structure may be able to handle all
transactions at first, growth will likely force expensive and extensive
remodeling.

Tepees vs Skyscrapers, I guess.

This is probably fragmented, but so is my brain right now. :)


On Mon, Jan 4, 2010 at 8:30 AM, Robert Cummings wrote:

> Richard Quadling wrote:
>
>> 2009/12/30 Tony Marston :
>>
>>> 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,
>>>
>>
> Design patterns re-use the approach to solving a particular problem set.
> Note that I said approach, because the code may not be re-usable, but the
> tenets of the solution are embodied by the pattern regardless of the
> language used. In this way, design patterns are indeed re-usable. When you
> see that a particular problem falls within the domain of a Design Pattern,
> then the implementation is straightforward since you can use the design
> pattern to guide your implementation.
>
>
> 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?
>>>
>>
> Each subsequent use of a design pattern should indeed require less effort.
> As you absorb fully the pattern, it becomes easier and easier to see how
> problems fit within one pattern or another or multiple patterns. Having at
> that point already implemented solutions using design patterns, it should
> become easier each time you create a solution using a previously used design
> pattern.
>
>
> 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-dea d.html and
>>> http://www.tonymarston.net/php-mysql/transaction-patterns.ht ml ) 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?
>>>
>>
> If I ask you to classify bugs by genus, does it not become easier and
> easier to classify any given bug based on your previous experience of
> knowing what constitutes membership in a particular genus? The same is true
> of design patterns.
>
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--0016e6d99ed5d155d2047c6fd534--