On Aug 8, 5:02 am, Steven D'Aprano <steve +comp.lang.pyt...@pearwood.info> wrote: > I haven't read the Gang of Four book itself, but I've spent plenty of > time being perplexed by over-engineered, jargon-filled code, articles, > posts and discussions by people who use Design Patterns as an end to > themselves rather than a means to an end. (Singleton is notoriously bad > in that way.)
The Go4 book isn't perfect, and I don't agree with all of their patterns. But they themselves made it very clear that _you're not supposed to_. It's meant to provide a mechanism for discussion and debate. It's _just another tool for development_; it's not a silver bullet, and anyone who claims otherwise is just a desperate marketing shill. _Not_ using a pattern should be as much a part of any conversation as using it. (But then, I love the word "synergy" too. Just because something has been driven into the ground through marketing misuse or overeager misapplication doesn't make the basic concept itself worthless.) > I think that as languages get more powerful, "Design Patterns" just > become language features, and people stop talking about them. Nobody > talks about Function Pattern, but everyone uses it. In Python, we don't > talk about the Iterator Pattern. We just use iterators. I'm not making the distinction between "iterator pattern" and "iterators". Talking about one is talking about the other. That's _all_ I see design patterns as: naming and defining commonly re-used aspects of functionality. Not invention, recognition. > I'm pretty sure that people could talk about good coding design before > the Gof4. As you say, they didn't invent the patterns. So people > obviously wrote code, and talked about algorithms, without the Gof4 > terminology. So what did people call Singletons before the pattern was named? If I was talking about "global uniques" and you were talking about "single instantiation", would we even recognise we were discussing the same thing? The Go4 book was as much about the approach of naming and documenting patterns as describing the patterns they saw. It was just an attempt at formally approaching what we were previously doing anyway. > I don't think that "Memento Pattern" is any more clear than "save and > restore". And I don't think that everyone making up their own terminology helps with the _communicativeness_ of code. > And the ever-finer distinctions between variations on patterns. Without > looking them up, what are the difference between Default Visitor, > Extrinsic Visitor, Acyclic Visitor, Hierarchical Visitor, Null Object And > Visitor, and regular old Visitor patterns? -- and no, I did not make any > of them up. Why wouldn't I look them up? The point is that they represent experience with solving certain problems. _Someone_ felt the distinction was necessary; by their documenting it I can read it and decide whether the distinction is relevant to me. Maybe they considered edge cases I didn't. But telling me _not_ to look at the definition of a design pattern and just "intuit" it's meaning is, again, missing the point of having a means of communicating experience with specific problem domains. -- http://mail.python.org/mailman/listinfo/python-list
