Looking for a good introduction to object oriented programming with Python

alex23 wuwei23 at gmail.com
Wed Aug 8 02:07:59 CEST 2012

On Aug 8, 5:02 am, Steven D'Aprano <steve
+comp.lang.pyt... at 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

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.

More information about the Python-list mailing list