"The pattern language does not tell you how to design anything. It helps you decide what should be designed. You get to make up whatever patterns you think will lead to good designs."
Impressive insight.
“Design Patterns” Aren't (2002)
61–70 of 133 posts
Re: “Design Patterns” Aren't (2002)
#62From the description, it sound like Domain Driven Design is a better fit for "a pattern language" than software patterns are.
Re: “Design Patterns” Aren't (2002)
#63I didn't think you were supposed to copy the code out of the book. GOF was trying to define the vocabulary, and the code was just examples.
Re: “Design Patterns” Aren't (2002)
#64Two years after this was published, Domain Driven Design was released, which among other things talked about using a ubiquitous language to ensure all members of a team creating some software were on the same page. So it seems disingenuous to imply the software design community were completely oblivious of these nuances in Alexander's work.
More widely, addressing the slightly snidey remarks about C++, which form the basis of most attacks on design patterns - this idea that design patterns are snippets of code certainly did take root, and persists to this day. Even with DDD, people missed many of the more interesting 'soft' factors addressed, and walked away from the book thinking all they needed to do was rename their data access objects 'repository'.
But it's utterly useless to say that iterators as a concept are pointless because foreach exists (and whether or not the author wants to believe people are missing the point, this is the foot they launch off from). Languages with first class functions are popular today, and I still hear that you don't need the strategy pattern because of this. And yet I look at Python's urllib (literally today), and its retry mechanism is configured by supplying a value telling it what to do. It's doesn't expose an interface to make the decision yourself. Design patterns in software (whatever the ancestry of the phrase) give you a better granularity to discuss, think about and plan software design. Sure, we have more retrospective patterns, but that's as much to do with the fact that we make a ton more software than architects make buildings.
I certainly agree that we haven't, as a community, got full value out of even our own interpretation of design patterns. But I don't think it's because of any of the issues described in this talk, and I certainly don't think it's because of the limitations of our programming languages.
Re: “Design Patterns” Aren't (2002)
#65The thing very few people seem to get about Design Patterns (in the gang-of-four sense): they are not a Good Thing, desirable and worthy of study in and of themselves. They are a necessary evil to compensate for fundamental deficiencies in C-like programming languages.
Especially object oriented languages.
Re: “Design Patterns” Aren't (2002)
#66Earlier quoted context omitted.
From the postscript of this slide deck: It appears to me that almost everyone who has read this has completely missed the point, even though I said it twice in big letters. People keep sending me mail that says things like this: > I just read through you article "Design Patterns" Aren't. I'm afraid you got it all backwards. At least the iterator example is totally flawed. Or people spend a lot of time arguing about h…
It appears to me that almost everyone who commented on my comment completely missed the point, even though i made it three different ways. Why do people focus on paragraph 2, when paragraph 5 is where i make the real point? Facing a big coding challenge is hard, and having an abstract language for describing how to structure a solution is valuable to the point of protecting sanity. I have a few theories. One theory i…
Spoken like a true perl programmer
Re: “Design Patterns” Aren't (2002)
#67I remember reading this when it was new. foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard. On large java projects it seems like composite/facade for days. Those splits seemed to let teams work t…
I'm a 40-something programmer learning to weld. It's really fun! You can do it too.
Re: “Design Patterns” Aren't (2002)
#68I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program. They can also be useful in a context where not eve…
>I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later.
I've seen a big project with heavy emphasis on patterns, and it was a hell for new programmers. Take a month debugging 50 levels of method calls trough the facades and the framework, just to find code that does the business logic.
Re: “Design Patterns” Aren't (2002)
#69"The Gang-of-Four idea is to discover existing patterns of software development. Then program people to implement them habitually" Citation needed. GoF's intention was to give people a tool for thinking about architecture and sharing their experiences with others. If people are "programmed to implement them habitually", that's some manager's fantasy and neither in the letter or spirit of Design Patterns. It's be like…
> that's some manager's fantasy The issue is that in a lot of shops design patterns have turned into a religion and not just a tool to help thinking. I've seen managers like that. If you didn't implement 15 different design patterns in this or that code base that was "bad design", even if it unnecessarily made the code more complex. I've seen iterators classes written when a simple for loop would have done the trick.…
Agree, that's a real issue, just like managers who treat agile as a religion and sadly give a fundamentally good thing a bad name.
Good programmers know the importance of YAGNI and the root of all evil that is premature optimisation. They should be well equipped to avoid over-engineering while still getting the learning benefits of patterns.
Chain of responsibility, for example, is a pattern I learned via GoF, have found it to be useful on several occasions. I quite possibly never would have known about it otherwise. At best, it would be left to chance for me to stumble on it or refactor into it enough times to recognise the pattern.
Re: “Design Patterns” Aren't (2002)
#70I remember reading this when it was new. foreach only works on a list. I can bless a list of lists into a rose tree, but i can't traverse that in a uniform way. There's just no hook to say, when the thing isn't a list, get the next element like this. Now days i'd point at haskell's traversable as the gold standard. On large java projects it seems like composite/facade for days. Those splits seemed to let teams work t…
From the postscript of this slide deck: It appears to me that almost everyone who has read this has completely missed the point, even though I said it twice in big letters. People keep sending me mail that says things like this: > I just read through you article "Design Patterns" Aren't. I'm afraid you got it all backwards. At least the iterator example is totally flawed. Or people spend a lot of time arguing about h…
I mean, lots of people can't read for crap, but at some point, some of the failure to communicate has to fall on the one doing the talking.