4 ms·
I'd completely agree that, at their core, design patterns are simply words or phrases that can loosely define what a program can do without getting as specific
by noobiemcfoob 10y ago
I'd completely agree that, at their core, design patterns are simply words or phrases that can loosely define what a program can do without getting as specific as even pseudocode.
I believe there is some element to aspiring to use them though. Once something becomes common enough to be called a design pattern that 2+ independent developers might recognize, that's the signal of a common problem that might have better solutions than the first couple you come up with in planning.
If a design pattern becomes really common, perhaps enough developers get together and add a feature to a language (or make a new one) to encompass what was once a common bit of spaghetti code.
- 3minus1 10y agoI've heard the quote about design patterns making up for the lack of features in a language. I've always been a little confused by it. Can you give me a good example of a language feature that removes the need for a design pattern?
- thristian 10y agoIn Java, you'll sometimes see people handing around instances of nearly (or entirely) empty classes with a single method, for use as callbacks. In languages with first-class functions, you can just hand around function pointers directly, you don't need to dress them up with classes. In C, you'll sometimes see people make a struct containing only a collection of function pointers, and different parts of the code will produce instances of the struct with the function pointers populated differently. In languages with built-in polymorphism, this isn't necessary.
- lmm 10y agoA language-level match feature replaces many use cases of the visitor pattern. Typeclasses often remove the need for facades. First-class constructors (e.g. static virtual methods) remove the need for factories.