5 ms·

All these comments are terribly reactionary. I completely agree with the author. Before you write a design pattern, abstraction, or interface, ask yourself: I

All these comments are terribly reactionary. I completely agree with the author. Before you write a design pattern, abstraction, or interface, ask yourself: Is this the simplest possible thing that can work? And then: Will I ever touch this code again? And then: How hard would this be to rewrite if the requirements change? Design patterns were meant to future proof code, but usually they just introduce complexity and useless abstraction, or serve to paper over limitations of your language. You probably can't predict the future as well as you think you can. Your program is a document. You can change it. You can make it do anything.

couchand 9y ago
> Design patterns were meant to future proof code That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. > paper over limitations of your language. See http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures
- hinkley 9y ago
  Whenever anyone asks me if they should read Design Patterns by Gamma et al, I tell them to go read Refactoring. If they say they've already read it I tell them to read it again. The patterns are loosely what to do, but that's not the thing that lasts across the years and languages. Refactoring is why and how.
- geezerjay 9y ago
  > That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. I would add that IIRC Martin Fowler himself, a manwho writes whole books dedicated to desing patterns and software design, is also the man behind the "monolithic design first" mantra.
watwut 9y ago
I have read the original design pattern book and future proofing the code was not mentioned. They always started with existing requirements.
lucozade 9y ago
> Design patterns were meant to future proof code Not exactly, most of them are intended to encapsulate change. If you don't have a reasonable idea how your system is likely to change then they're mostly useless. > You probably can't predict the future as well as you think you can It's not at all unusual for people to be good at predicting where change will occur, even if they don't know exactly what the change is. In my field, I have a very good understanding as to where the industry is heading and I design accordingly. > Your program is a document. You can change it. You can make it do anything. Sure, if you're talking about a project with a couple of man years work in it. That's not really the space that design patterns were intended for.

couchand 9y ago

> Design patterns were meant to future proof code That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. > paper over limitations of your language. See http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures http://wiki.c2.com/?DesignPatternsAreMissingLanguageFeatures

hinkley 9y ago
Whenever anyone asks me if they should read Design Patterns by Gamma et al, I tell them to go read Refactoring. If they say they've already read it I tell them to read it again. The patterns are loosely what to do, but that's not the thing that lasts across the years and languages. Refactoring is why and how.
geezerjay 9y ago
> That's a misguided but unfortunately common view. Best practice is to refactor to patterns, don't try to divining them from the start. I would add that IIRC Martin Fowler himself, a manwho writes whole books dedicated to desing patterns and software design, is also the man behind the "monolithic design first" mantra.

watwut 9y ago

I have read the original design pattern book and future proofing the code was not mentioned. They always started with existing requirements.

lucozade 9y ago

> Design patterns were meant to future proof code Not exactly, most of them are intended to encapsulate change. If you don't have a reasonable idea how your system is likely to change then they're mostly useless. > You probably can't predict the future as well as you think you can It's not at all unusual for people to be good at predicting where change will occur, even if they don't know exactly what the change is. In my field, I have a very good understanding as to where the industry is heading and I design accordingly. > Your program is a document. You can change it. You can make it do anything. Sure, if you're talking about a project with a couple of man years work in it. That's not really the space that design patterns were intended for.