Pythonic design patterns

[Steven D'Aprano]

On Thu, 04 Dec 2008 01:09:08 -0800, Slaunger wrote:

> I find myself spending a lot of time in Python making some designs, to
> solve some task, which is the end turn out to be closely related to well
> established design patterns / programming idioms, which other users in
> this forum has been kind enough to point out. Only my implementations
> are often not that clean, and I may call things something different than
> the normal convention, which is a source of confusion for myself and
> others trying to communicate with me.
> 
> I guess I could boost my productivity by learning these well-proven and
> well-established design patterns by heart.

This is all very good, but don't drink the design pattern Kool-Aid and 
start pushing design patterns everywhere. (Not everything needs to be a 
singleton. No, really.)

I think the risk with design patterns is that in the hands of an over-
enthusiastic new convert, they encourage over-engineering, excessive 
abstraction and Big Design Up Front thinking. Patterns are useful, 
there's no doubt about it, but patterns should for the most part be 
invisible. Functions are patterns, but because they were invented back 
when dinosaurs walked the earth, before the Gang Of Four, they're just 
called functions instead of AbstractReusableResultGeneratingValueFactory 
Pattern. *wink*

http://c2.com/cgi/wiki?DesignPatternsConsideredHarmful

I think one good sign of pattern over/mis-use is when people can't even 
agree on whether something is a pattern, and if so, which pattern it is:

http://c2.com/cgi/wiki?FactoryMethod




-- 
Steven