3 ms·

My impression was that design patterns are just shared vocabulary, not something to aspire to use (other than realizing there was an existing "word" that would

by lfowles 10y ago

My impression was that design patterns are just shared vocabulary, not something to aspire to use (other than realizing there was an existing "word" that would succinctly describe your jumbled spaghetti sentence and using that instead). Edit: I've been wanting to read A Pattern Language for a while, but this snippet from Amazon made me chuckle. If I didn't know better, I would have given it a 50/50 shot of being from APL or GoF! >The elements of this language are entities called patterns. Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.

jomamaxx 10y ago
This. Design Patters are simply tools at a higher level of abstraction than the code itself. They are 'approaches to modelling information'. That's it. Use them, hack them, or not. I've found them handy enough, though never implemented anything precisely. They make sense when communicating ideas as well. I don't see why there is a need for debate.
draw_down 10y ago
Right, if you do the same handful of things over and over again, you eventually realize that it helps to have a way to talk about those things at a higher level. It's nothing too serious.
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 ago
  I'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 ago
    In 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 ago
    A 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.
rtpg 10y ago
I think that's what they are in the industry right now. We all use the same vocabulary, and it makes sense to share a lot, since we're mostly doing the same thing. The slides' point seems to be that there's this other concept, which is that each project should develop a language for speaking of the project, perhaps more specific to the project. But also not just a list of "things people use currently". Your new projects could include completely new design patterns. So the idea when starting a project is : when designing, define concepts that you will use a lot. For example, you might be using a lot of iterators. But for the designers of Angular, you're working with promises, with controllers, with scopes. Use this language when trying to frame problems, and people will build off the same base. When people start coding, everyone starts off the same foundation. But that foundation doesn't need to just be "the design patterns from all over". You can have your own design patterns, more specific for your project. Have your best developers choose the right design patterns for the project, and even the most junior developers will be guided by this when working on the details.
- noobiemcfoob 10y ago
  The last portion of your comment reminds me of the themes from Mythical Man Month by Fred Brooks.

by lfowles 10y ago

jomamaxx 10y ago

This. Design Patters are simply tools at a higher level of abstraction than the code itself. They are 'approaches to modelling information'. That's it. Use them, hack them, or not. I've found them handy enough, though never implemented anything precisely. They make sense when communicating ideas as well. I don't see why there is a need for debate.

draw_down 10y ago

Right, if you do the same handful of things over and over again, you eventually realize that it helps to have a way to talk about those things at a higher level. It's nothing too serious.

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 ago
I'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 ago
  In 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 ago
  A 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.

rtpg 10y ago

I think that's what they are in the industry right now. We all use the same vocabulary, and it makes sense to share a lot, since we're mostly doing the same thing. The slides' point seems to be that there's this other concept, which is that each project should develop a language for speaking of the project, perhaps more specific to the project. But also not just a list of "things people use currently". Your new projects could include completely new design patterns. So the idea when starting a project is : when designing, define concepts that you will use a lot. For example, you might be using a lot of iterators. But for the designers of Angular, you're working with promises, with controllers, with scopes. Use this language when trying to frame problems, and people will build off the same base. When people start coding, everyone starts off the same foundation. But that foundation doesn't need to just be "the design patterns from all over". You can have your own design patterns, more specific for your project. Have your best developers choose the right design patterns for the project, and even the most junior developers will be guided by this when working on the details.

noobiemcfoob 10y ago
The last portion of your comment reminds me of the themes from Mythical Man Month by Fred Brooks.