6 ms·

>What is a Pattern? >An 'element of reusable software' >A design pattern systematically names, motivates, and explains a general design that addresses a recur

>What is a Pattern? >An 'element of reusable software' >A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object-oriented systems. It describes the problem, the solution, when to apply the solution, and its consequences. It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context. Interesting to note that the person defines a pattern as something exclusive to using Objects and classes or in other words OOP. So something like lenses or functors or programming techniques defined outside of OOP are not patterns. When I talk to people they often define design patterns as a common language for various methods that are common to programming and not exclusive to OOP. Doesn't english and vocabulary fill this space? You don't find carpentry workers referring to domain specific vocabulary as design patterns. Why don't FP practitioners or mathematicians call their techniques "patterns"? This may piss some people off and get me a load of downvotes, but honestly IMO I find design patterns to be just snobbery. Instead of saying someone is iterating through a list they say that someone is using the iterator pattern. It's really just prefixing the word "pattern" onto some vocabulary. I used the number pattern on the variable pattern and the addition pattern to get the sum of two numbers. I would've just called the book "Programming Tricks for OOP" rather then "Design Patterns."

alisonkisk 6y ago
FP programmers call their patterns Typeclass Laws. Mathematicians aren't building/designing things all day long so they don't need this word. "A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language." (Wikipedia on Pattern Language).
- neonological 6y ago
  >Mathematicians aren't building/designing things all day long so they don't need this word. Not true, they build proofs. Within proofs there are many many common techniques, aka "patterns." Either way you seem to imply that "patterns" are for people who "build" things, which isn't emphasized in your definition below: >"A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language." The problem with the above definition is that English vocabulary already communicates what a pattern does perfectly fine. What is the point coming up with an over complex name and postfixing all of these things with "pattern?" It's basically a redundant concept. In fact, my communication with you at this very moment is employing many many common patterns. Check the pattern in the previous sentence "many many." I call it the double emphasis pattern and I've used that pattern twice in this reply. I'll write more about it in my book on Design patterns for English communication.
  - kthejoker2 6y ago
    I think the simplest response I can give to this is the "above defition" is of a pattern language, not a pattern. A pattern language is an organized and coherent set of patterns. They are developed holistically to work in relation with each other. They're designed to be combined together - as sequences, in parallel, as contrasts - and also to be as "platform-agnostic" as possible. For example, Alexander's book helpfully includes a ton of points on how to combine the various patterns in the book, and a healthy "see also:" section to get alternative ideas or just areas of overlap between them all. And the patterns in the book are about the physical, environmental, and social needs of humans (the problems) and how they can be met trough architecture and infrastructure. It's very distinct from just "a list of patterns." They're always described in service to the whole, in relation to the others. For the English language, I would say Aristotle's Rhetoric is closest in spirit; whereas Elements of Style is clearly more a "list of patterns" Other "pattern language"-style books I can think of are The Prince by Machiavelli; Capital by Marx; 22 Immutable Laws of Marketing by Ries and Trout; Diffusion of Innovations by Rogers; and High Output Management by Andrew Grove. I would also say the original C2 Wiki comes closest to creating a "bottoms-up" pattern language. Here's the entry on A Pattern Language - https://wiki.c2.com/?PatternLanguage https://wiki.c2.com/?PatternLanguage But these books aren't explicitly set up as pattern language books - nor are many others. Very few books (not even the GoF) are put together so well and as comprehensively as A Pattern Language. It's truly a masterpiece.
    - neonological 6y ago
      I think that's where your bias lies. If you think a book is a masterpiece no amount of evidence can flip that bias. You post basically declares every scientific or academic or professional field as "pattern languages." Then you conclude to say.that there are books much more well put together then the gof book. I agree, like pretty much every axiomatic math book that proves each theorem starting from base axioms is more elegantly put together than GoF. And none of these books have the pretentiousness to call what they're doing a "pattern language." The concept is unecessary and is only used by books that are actually very informal. The Gof book is essentially just "oop programming tricks" retitled to "design patterns" to sound more academic when in fact its so far from academia, most schools don't teach it as part of foundational computer science. Also all the books you defined are informal and opinionated. Especially capital by marx. None of those books come close to the rigor of "pattern languages" established by even a basic math book on number theory.
bluefirebrand 6y ago
> This may piss some people off and get me a load of downvotes, but honestly IMO I find design patterns to be just snobbery 100%. I recently was interviewing so I decided to brush up on some design pattern terminology because plenty of job postings reference them and I didn't study them in school. I was blown away by how much of it's just complex-sounding terms for simple concepts. I was also surprised how poorly defined they really are.
- neonological 6y ago
  Agreed. Also note that school generally doesn't teach it because these patterns don't have any formal basis in theory. It's the complex vocabulary that gives these things more academic weight than they actually have. "Tricks of the trade" doesn't sound as rigorous as "Design Patterns" but really it's the same thing.
pc86 6y ago
I agree with 99% of what you said - I think a lot of simpler patterns aren't actually "patterns" in the first place, iterator probably being the best example. However, for things like factories and things more complicated than that, it is helpful to have a lot of context come along with just a word or two. If someone says "facade" or "memento" you know exactly what they mean.
- neonological 6y ago
  Sure call it an iterator, call it facade. Naming things for the purpose of abstracting away complexity is one of the foundational functions of the English language. But there's no need to group what is essentially just English Vocabulary into another sub category of "language" prefixed with "design" and then post-fix all internal concepts with "pattern."
mirekrusin 6y ago
It feels like arguing about colors from the whole spectrum of the rainbow without saying which color we're arguing about. The point of patterns is to recognise things that reoccur all the time, ie. DFS is a pattern, FIFO queue as well, so stack, parser combinator, microservice, optimistic locking, proxy, demux etc. The whole point it to use common volabulary where you can drop this "pattern" suffix when discussing things. It can be anything, GoF described an idea and couple of patterns in OO context, there are many other books "Analysis Patterns", "Enterprise Integration Patterns", "Patterns of Enterprise Application Architecture" etc.
- neonological 6y ago
  > It feels like arguing about colors from the whole spectrum of the rainbow without saying which color we're arguing about. Arguing about a rainbow or arguing about a color in the rainbow doesn't effect the validity of an argument, I'm not sure your analogy makes any fundamental sense here. >The whole point it to use common vocabulary where you can drop this "pattern" suffix when discussing things. Isn't this the purpose of the English language? The "Design Pattern" concept is a redundant concept existing recursively in English. English already provides a "common vocabulary" for "discussing things." What does design patterns provide on top of that? Only additional complexity and redundancy. That's why basically all fields outside of programming don't really use the word "design pattern" because it's not necessary. It's a bit of snobbish for a pilot to call a flight technique a "design pattern." >It can be anything, And that's why it's pointless. There are even design patterns in poetry if you follow this line of logic. The English language is pretty much the "language" designed to be "anything." For a concept within "English" to be useful it must focus on a smaller subset of "anything."
  - jcelerier 6y ago
    > What does design patterns provide on top of that? Only additional complexity and redundancy. understanding each other would be impossible if we just said, e.g. strategy or command. "we use a strategy" can mean a ton of stuff in the context of a chat between developers in a company. "we use the strategy pattern" will be clear to everyone.
xapata 6y ago
I share your distaste for cargo cult programming, but ... iterating over a list can be done in multiple ways, and doesn't necessarily mean one is using the iterator pattern. Using the jargon "iterator" to refer to an object or closure that tracks the state of iteration has benefit in making conversation more concise.
- neonological 6y ago
  Sure, my point is don't attach the word "pattern" to the end and don't call it a "design pattern" You're just iterating through a list and calling it "iterating" is perfectly fine. Don't get me wrong. Naming things to abstract away complexity is perfectly fine and a foundational aspect of the English language. Naming something the "iterator pattern" and calling it a concept within the sub field of "Design patterns" is the snobbery I'm referring to.
  - xapata 6y ago
    The iterator pattern is the use of an object or closure to encapsulate the state of the iteration. This is distinct from using a loop induction variable in the same scope as the loop block itself. In a language like C, which doesn't provide iterators by default, it seems reasonable to call that a design pattern.
    - neonological 6y ago
      It seems more reasonable to say you're iterating through a collection. It also seems more reasonable to just leave it as a programming technique rather then give it artificial weight and call it some bloated unnecessary academic term "design pattern"
      - xapata 6y ago
        Ok, call it the iterator technique, but there's a difference between using the iterator technique and iterating, which you seem to be refusing to acknowledge.
jcelerier 6y ago
> You don't find carpentry workers referring to domain specific vocabulary as design patterns. they don't call it a "design pattern", but a "technique". see e.g. https://www.amazon.fr/Woodwork-Step-Carpentry-Techniques-Made/dp/0744026873 https://www.amazon.fr/Woodwork-Step-Carpentry-Techniques-Mad... or http://www.basiccarpentrytechniques.com/ http://www.basiccarpentrytechniques.com/ to me, "hip roof framing" or "trench shoring" definitely sounds like "applying a visitor" or "implementing an abstract factory" would sound to a non-software-engineer carpenter.
- neonological 6y ago
  Yeah and a technique is part of the "English" language. Techniques exist everywhere. But in computer science they had to basically make the same concept sound more snobbish. These aren't programming techniques, they are "design patterns."
  - deleted 6y ago
    [deleted]
  - ratww 6y ago
    I agree with you and the TFA. I also think that naming the book "Design Patterns" and calling the techniques "Patterns" is unfortunate and misleading. But I think calling them like that is what made the book as famous and as is it. If the book were called "OOP Programming Techniques" it wouldn't have the same popularity. Of course that doesn't make it right. As a book it has served its purpose at the time, but by portraying what are basically "band aids" to limited programming languages (Norvig 1996) as foundational CS knowledge, it ossified the development of OOP and CS itself by a few years IMO.
rbonvall 6y ago
FP practitioners are guilty of this as well, when talking about "the Maybe monad" or "the IO monad".
- neonological 6y ago
  Naming stuff is ok. I understand this. It's done in every field. But calling the "naming of things" a "design pattern" is pretentious. Nobody calls Monads the "Monad pattern" and categorizes it as a sub field of "design patterns." It's just like how we abstract the concept of getting into a car and commanding the car under the word "driving." That's fine. What's wrong is if We called it the "driving pattern" and place it an area of study within the automobile field called "design patterns." Imagine if some expert race driver publishes a driving book called "Design patterns" then with an analogy relates it to architecture. Why not just call the book "Driving techniques" and eschew the useless analogy? I'll tell you why the GoF did this. Because "Design patterns" sounds more academic, and the catharsis of realizing the analogy between architecture and programming techniques inflates the perception of what these concepts actually are. In the end these are just programming tricks or techniques.
- ratww 6y ago
  But both those things are Monads. They follow the Monad laws, the conform to a certain Monad interface, they both have bind and return, they behave like Monads. To me the problem with using "pattern" is that it suggests a relationship when there's none, other than all of them being techniques that were presented in the same book. Prematurely naming them also prevented other people from finding better names. For example, other techniques that are in the same idea-space, such as "Inversion of Control" and "Dependency Injection" don't need the "pattern" suffix, for example, but are still understandable.
munchbunny 6y ago
> Doesn't english and vocabulary fill this space? Yes, and no. English doesn't by default fill the space of words that are shorthands for domain specific ideas. The practitioners coin the terms. > You don't find carpentry workers referring to domain specific vocabulary as design patterns. Every field has its conventions, shorthands, patterns, etc. They might not call them design patterns. Lawyers, for example, have tons and tons of terms that are shorthand for complex concepts, and you wouldn't understand them without first studying them, even if they are strictly made of otherwise mundane English words. For example, "strict scrutiny", or "reasonable person".
- neonological 6y ago
  >English doesn't by default fill the space of words that are shorthands for domain specific ideas. That was a rhetorical question. I beg to differ. English does fill the space of all kinds of of domain specific areas. Practitioners may invent new vocabulary to use within the English language but in the end they are still using English. In fact even when you talk about "Design patterns" You are still using "English" it's inescapable. I'm saying the extra layer of "design patterns" as a "field" is not necessary. No other "domain" is snobbish enough to call their techniques "patterns" and group them as "design patterns" and fill the field with all this jargon like "strategy pattern." It's just programming techniques, carpentry techniques and the like.

alisonkisk 6y ago

FP programmers call their patterns Typeclass Laws. Mathematicians aren't building/designing things all day long so they don't need this word. "A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language." (Wikipedia on Pattern Language).

neonological 6y ago
>Mathematicians aren't building/designing things all day long so they don't need this word. Not true, they build proofs. Within proofs there are many many common techniques, aka "patterns." Either way you seem to imply that "patterns" are for people who "build" things, which isn't emphasized in your definition below: >"A pattern language is an organized and coherent set of patterns, each of which describes a problem and the core of a solution that can be used in many ways within a specific field of expertise. The term was coined by architect Christopher Alexander and popularized by his 1977 book A Pattern Language." The problem with the above definition is that English vocabulary already communicates what a pattern does perfectly fine. What is the point coming up with an over complex name and postfixing all of these things with "pattern?" It's basically a redundant concept. In fact, my communication with you at this very moment is employing many many common patterns. Check the pattern in the previous sentence "many many." I call it the double emphasis pattern and I've used that pattern twice in this reply. I'll write more about it in my book on Design patterns for English communication.
- kthejoker2 6y ago
  I think the simplest response I can give to this is the "above defition" is of a pattern language, not a pattern. A pattern language is an organized and coherent set of patterns. They are developed holistically to work in relation with each other. They're designed to be combined together - as sequences, in parallel, as contrasts - and also to be as "platform-agnostic" as possible. For example, Alexander's book helpfully includes a ton of points on how to combine the various patterns in the book, and a healthy "see also:" section to get alternative ideas or just areas of overlap between them all. And the patterns in the book are about the physical, environmental, and social needs of humans (the problems) and how they can be met trough architecture and infrastructure. It's very distinct from just "a list of patterns." They're always described in service to the whole, in relation to the others. For the English language, I would say Aristotle's Rhetoric is closest in spirit; whereas Elements of Style is clearly more a "list of patterns" Other "pattern language"-style books I can think of are The Prince by Machiavelli; Capital by Marx; 22 Immutable Laws of Marketing by Ries and Trout; Diffusion of Innovations by Rogers; and High Output Management by Andrew Grove. I would also say the original C2 Wiki comes closest to creating a "bottoms-up" pattern language. Here's the entry on A Pattern Language - https://wiki.c2.com/?PatternLanguage https://wiki.c2.com/?PatternLanguage But these books aren't explicitly set up as pattern language books - nor are many others. Very few books (not even the GoF) are put together so well and as comprehensively as A Pattern Language. It's truly a masterpiece.
  - neonological 6y ago
    I think that's where your bias lies. If you think a book is a masterpiece no amount of evidence can flip that bias. You post basically declares every scientific or academic or professional field as "pattern languages." Then you conclude to say.that there are books much more well put together then the gof book. I agree, like pretty much every axiomatic math book that proves each theorem starting from base axioms is more elegantly put together than GoF. And none of these books have the pretentiousness to call what they're doing a "pattern language." The concept is unecessary and is only used by books that are actually very informal. The Gof book is essentially just "oop programming tricks" retitled to "design patterns" to sound more academic when in fact its so far from academia, most schools don't teach it as part of foundational computer science. Also all the books you defined are informal and opinionated. Especially capital by marx. None of those books come close to the rigor of "pattern languages" established by even a basic math book on number theory.

bluefirebrand 6y ago

> This may piss some people off and get me a load of downvotes, but honestly IMO I find design patterns to be just snobbery 100%. I recently was interviewing so I decided to brush up on some design pattern terminology because plenty of job postings reference them and I didn't study them in school. I was blown away by how much of it's just complex-sounding terms for simple concepts. I was also surprised how poorly defined they really are.

neonological 6y ago
Agreed. Also note that school generally doesn't teach it because these patterns don't have any formal basis in theory. It's the complex vocabulary that gives these things more academic weight than they actually have. "Tricks of the trade" doesn't sound as rigorous as "Design Patterns" but really it's the same thing.

pc86 6y ago

I agree with 99% of what you said - I think a lot of simpler patterns aren't actually "patterns" in the first place, iterator probably being the best example. However, for things like factories and things more complicated than that, it is helpful to have a lot of context come along with just a word or two. If someone says "facade" or "memento" you know exactly what they mean.

neonological 6y ago
Sure call it an iterator, call it facade. Naming things for the purpose of abstracting away complexity is one of the foundational functions of the English language. But there's no need to group what is essentially just English Vocabulary into another sub category of "language" prefixed with "design" and then post-fix all internal concepts with "pattern."

mirekrusin 6y ago

It feels like arguing about colors from the whole spectrum of the rainbow without saying which color we're arguing about. The point of patterns is to recognise things that reoccur all the time, ie. DFS is a pattern, FIFO queue as well, so stack, parser combinator, microservice, optimistic locking, proxy, demux etc. The whole point it to use common volabulary where you can drop this "pattern" suffix when discussing things. It can be anything, GoF described an idea and couple of patterns in OO context, there are many other books "Analysis Patterns", "Enterprise Integration Patterns", "Patterns of Enterprise Application Architecture" etc.

neonological 6y ago
> It feels like arguing about colors from the whole spectrum of the rainbow without saying which color we're arguing about. Arguing about a rainbow or arguing about a color in the rainbow doesn't effect the validity of an argument, I'm not sure your analogy makes any fundamental sense here. >The whole point it to use common vocabulary where you can drop this "pattern" suffix when discussing things. Isn't this the purpose of the English language? The "Design Pattern" concept is a redundant concept existing recursively in English. English already provides a "common vocabulary" for "discussing things." What does design patterns provide on top of that? Only additional complexity and redundancy. That's why basically all fields outside of programming don't really use the word "design pattern" because it's not necessary. It's a bit of snobbish for a pilot to call a flight technique a "design pattern." >It can be anything, And that's why it's pointless. There are even design patterns in poetry if you follow this line of logic. The English language is pretty much the "language" designed to be "anything." For a concept within "English" to be useful it must focus on a smaller subset of "anything."
- jcelerier 6y ago
  > What does design patterns provide on top of that? Only additional complexity and redundancy. understanding each other would be impossible if we just said, e.g. strategy or command. "we use a strategy" can mean a ton of stuff in the context of a chat between developers in a company. "we use the strategy pattern" will be clear to everyone.

xapata 6y ago

I share your distaste for cargo cult programming, but ... iterating over a list can be done in multiple ways, and doesn't necessarily mean one is using the iterator pattern. Using the jargon "iterator" to refer to an object or closure that tracks the state of iteration has benefit in making conversation more concise.

neonological 6y ago
Sure, my point is don't attach the word "pattern" to the end and don't call it a "design pattern" You're just iterating through a list and calling it "iterating" is perfectly fine. Don't get me wrong. Naming things to abstract away complexity is perfectly fine and a foundational aspect of the English language. Naming something the "iterator pattern" and calling it a concept within the sub field of "Design patterns" is the snobbery I'm referring to.
- xapata 6y ago
  The iterator pattern is the use of an object or closure to encapsulate the state of the iteration. This is distinct from using a loop induction variable in the same scope as the loop block itself. In a language like C, which doesn't provide iterators by default, it seems reasonable to call that a design pattern.
  - neonological 6y ago
    It seems more reasonable to say you're iterating through a collection. It also seems more reasonable to just leave it as a programming technique rather then give it artificial weight and call it some bloated unnecessary academic term "design pattern"
    - xapata 6y ago
      Ok, call it the iterator technique, but there's a difference between using the iterator technique and iterating, which you seem to be refusing to acknowledge.

jcelerier 6y ago

> You don't find carpentry workers referring to domain specific vocabulary as design patterns. they don't call it a "design pattern", but a "technique". see e.g. https://www.amazon.fr/Woodwork-Step-Carpentry-Techniques-Made/dp/0744026873 https://www.amazon.fr/Woodwork-Step-Carpentry-Techniques-Mad... or http://www.basiccarpentrytechniques.com/ http://www.basiccarpentrytechniques.com/ to me, "hip roof framing" or "trench shoring" definitely sounds like "applying a visitor" or "implementing an abstract factory" would sound to a non-software-engineer carpenter.

neonological 6y ago
Yeah and a technique is part of the "English" language. Techniques exist everywhere. But in computer science they had to basically make the same concept sound more snobbish. These aren't programming techniques, they are "design patterns."
- deleted 6y ago
  [deleted]
- ratww 6y ago
  I agree with you and the TFA. I also think that naming the book "Design Patterns" and calling the techniques "Patterns" is unfortunate and misleading. But I think calling them like that is what made the book as famous and as is it. If the book were called "OOP Programming Techniques" it wouldn't have the same popularity. Of course that doesn't make it right. As a book it has served its purpose at the time, but by portraying what are basically "band aids" to limited programming languages (Norvig 1996) as foundational CS knowledge, it ossified the development of OOP and CS itself by a few years IMO.

rbonvall 6y ago

FP practitioners are guilty of this as well, when talking about "the Maybe monad" or "the IO monad".

neonological 6y ago
Naming stuff is ok. I understand this. It's done in every field. But calling the "naming of things" a "design pattern" is pretentious. Nobody calls Monads the "Monad pattern" and categorizes it as a sub field of "design patterns." It's just like how we abstract the concept of getting into a car and commanding the car under the word "driving." That's fine. What's wrong is if We called it the "driving pattern" and place it an area of study within the automobile field called "design patterns." Imagine if some expert race driver publishes a driving book called "Design patterns" then with an analogy relates it to architecture. Why not just call the book "Driving techniques" and eschew the useless analogy? I'll tell you why the GoF did this. Because "Design patterns" sounds more academic, and the catharsis of realizing the analogy between architecture and programming techniques inflates the perception of what these concepts actually are. In the end these are just programming tricks or techniques.
ratww 6y ago
But both those things are Monads. They follow the Monad laws, the conform to a certain Monad interface, they both have bind and return, they behave like Monads. To me the problem with using "pattern" is that it suggests a relationship when there's none, other than all of them being techniques that were presented in the same book. Prematurely naming them also prevented other people from finding better names. For example, other techniques that are in the same idea-space, such as "Inversion of Control" and "Dependency Injection" don't need the "pattern" suffix, for example, but are still understandable.

munchbunny 6y ago

> Doesn't english and vocabulary fill this space? Yes, and no. English doesn't by default fill the space of words that are shorthands for domain specific ideas. The practitioners coin the terms. > You don't find carpentry workers referring to domain specific vocabulary as design patterns. Every field has its conventions, shorthands, patterns, etc. They might not call them design patterns. Lawyers, for example, have tons and tons of terms that are shorthand for complex concepts, and you wouldn't understand them without first studying them, even if they are strictly made of otherwise mundane English words. For example, "strict scrutiny", or "reasonable person".

neonological 6y ago
>English doesn't by default fill the space of words that are shorthands for domain specific ideas. That was a rhetorical question. I beg to differ. English does fill the space of all kinds of of domain specific areas. Practitioners may invent new vocabulary to use within the English language but in the end they are still using English. In fact even when you talk about "Design patterns" You are still using "English" it's inescapable. I'm saying the extra layer of "design patterns" as a "field" is not necessary. No other "domain" is snobbish enough to call their techniques "patterns" and group them as "design patterns" and fill the field with all this jargon like "strategy pattern." It's just programming techniques, carpentry techniques and the like.