4 ms·

>To qualify for the term “pattern”, an approach is not worthy until someone or some group has proven through some formal process that this approach is superior

>To qualify for the term “pattern”, an approach is not worthy until someone or some group has proven through some formal process that this approach is superior to all others, and qualifies as “best practice”. Since when? >An approach that earns the title of “pattern” not only becomes one tool in the toolbox, it becomes dogma. Well, this definition seems a wee bit dogmatic. >Everything that runs contrary to a given pattern becomes an “anti-pattern”. This is nonsense. edit - If I come up with a nicely thought through set of integrated UI elements that have not gone through any formal process or testing and asked someone what they thought of it as a pattern, I might expect to be asked, "How do you know it is a good pattern?" However I would not expect anyone to tell me, "You cannot use the term 'pattern' as it hasn't been proven through a formal process that this approach is superior to all others, and therefore qualifies as 'best practice'." If anyone did tell me this, I'd be looking for someone else to get feedback from.

EliRivers 7y ago
This is nonsense. Is that not the very point being made?
- stinos 7y ago
  Well, yes, but is there such nonsense to begin with? I.e. where does the original statement come form? Where is the canonical source claiming whatever is not a pattern, is an anti-pattern?
  - EliRivers 7y ago
    I have certainly worked in places where, for example, code consistency is rated so highly that writing bad code consistent with the existing codebase is considered preferable to writing good code. Quite literally pattern and anti-pattern.
    - mwfunk 7y ago
      Are you talking about formatting conventions or something else? Because if all you’re talking about is coding style, then yeah, it’s infinitely better to comply with the conventions of whatever your working on than do your own thing. For something as subjective as coding style, consistent vs inconsistent way more important than whether one style is used vs another one. That almost goes without saying.
      - EliRivers 7y ago
        No. I'm talking about things like endlessly copying horrifically monstrous multiple inheritance patterns, and painful single-threaded state machines instead of using threads to spin off work, and using shonky home-grown reference counting (that's thread-dangerous) instead of standard library smart pointers, and writing your own polymorphism instead of just using the inheritance that the language comes with, and leaving 80% of CPUs idle while trying to jam all the work into a single thread, and rewriting pieces of industry-standard libraries which then makes upgrading impossible, and writing horrifically heavy wrappers around simple DB access that turns modern DB interaction into sludge for the purpose of solving problems that the previous product had and the current product doesn't. Take all that, and then insist that all new code do that as well. That's what I'm talking about.
- inflatableDodo 7y ago
  The term pattern is not dependent on things being proven through formal processes and anti-patterns are not defined as things that are not patterns. Anti-patterns can be patterns that have been proven through formal processes and the most successful of them tend to be.
stinos 7y ago
^ came here to post pretty much this; author seems to try to make a fairly good point, but the way it comes out is a bit strange and lacking foundation. It almost reads like the author had a bad experience online or in real life where he was told he used an anti-pattern where he actually wasn't and now extrapolates this. Don't know, just guessing here. Sure there might be a group of not too well-informed/skilled people religously believing patterns must be used whenever even remotely possible and not using patterns is bad, mkay, but I think (hope?) the group considering them as just another tool in the toolbox, used when appropriate but not otherwise, is larger.
- EliRivers 7y ago
  Sure there might be a group of... Several. I've not worked in such an environment myself, but I've had colleagues who have; workplaces where every design is permitted only to use concepts from the big book of patterns and any situation to which they are inappropriate is nonetheless solved (badly) with that big book of patterns.
  - inflatableDodo 7y ago
    >workplaces where every design is permitted only to use concepts from the big book of patterns Can you name any of these workplaces?
    - EliRivers 7y ago
      The last chap who comes to mind I worked with who had previously worked in such a company was named Richard. Can't remember his last name, do remember I gave him a Wallace and Gromit moving toastrack as a leaving present when he went on to work for a flight sim company in the south west of England somewhere. I last worked with him when I was working for a UK offshoot of a US Defence company. This would have been somewhere around... six years ago, I guess. I suppose I could try to dig out his contact details and ask him, but I won't. So the short answer is no, I can't name that company. Got a feeling it was something involving printing, or imaging. I also cannot name any of the companies that any of my current colleagues have previously worked at. Is everyone else keeping track of where all their colleagues and ex-colleagues have worked? Wouldn't be surprised. I don't keep track of any of that. I'm not even on the facebook.
mikekchar 7y ago
In the original definition of "design pattern", it is a solution to a problem that has been generalised across multiple domains. In fact, a "pattern" is not a pattern unless it has been independently discovered by multiple different groups (I believe the original suggestion was 3). The point of a design pattern is not that it is superior it is that it is common. A design pattern is most assuredly not a best practice. In fact, it makes little sense to talk about a design pattern in isolation. It is a solution in a context. In some contexts it is appropriate and other contexts it is not appropriate. Design patterns used to have large preambles discussing the contexts where they were appropriate and where they were not. The point about an anti-pattern is that it is surprising. It must be a common approach that looks like it should work, but it doesn't. It is definitely not a "bad practice", or an "I don't like that" practice, or even an "inappropriately applied pattern". It's a surprising result that you should be aware of that tends to catch people frequently. Here is the first reference I know about discussing design patterns in software: https://c2.com/doc/oopsla87.html https://c2.com/doc/oopsla87.html (Yes, the "87" refers to "1987"). People who have only read about design patterns in the last decade or two are almost certainly missing the original point (as seems to be sadly common with these kinds of things).
- sitkack 7y ago
  To me, antipatterns are common modes of failure. Take for example a load balancer that is configured to send traffic to the fastest server at the time. Makes sense, if a server is fast it has more available capacity to handle requests. But when the front end code fails the server short circuits, skipping all the expensive code as it unwinds the stack and returns a 5XX error, the load balancer that just sends to the fastest now sends ALL traffic to the failing node. The antipattern is a feedback loop that is not measuring the right thing. In this case, they should be timing _successful_ calls to the front end.

EliRivers 7y ago

This is nonsense. Is that not the very point being made?

stinos 7y ago
Well, yes, but is there such nonsense to begin with? I.e. where does the original statement come form? Where is the canonical source claiming whatever is not a pattern, is an anti-pattern?
- EliRivers 7y ago
  I have certainly worked in places where, for example, code consistency is rated so highly that writing bad code consistent with the existing codebase is considered preferable to writing good code. Quite literally pattern and anti-pattern.
  - mwfunk 7y ago
    Are you talking about formatting conventions or something else? Because if all you’re talking about is coding style, then yeah, it’s infinitely better to comply with the conventions of whatever your working on than do your own thing. For something as subjective as coding style, consistent vs inconsistent way more important than whether one style is used vs another one. That almost goes without saying.
    - EliRivers 7y ago
      No. I'm talking about things like endlessly copying horrifically monstrous multiple inheritance patterns, and painful single-threaded state machines instead of using threads to spin off work, and using shonky home-grown reference counting (that's thread-dangerous) instead of standard library smart pointers, and writing your own polymorphism instead of just using the inheritance that the language comes with, and leaving 80% of CPUs idle while trying to jam all the work into a single thread, and rewriting pieces of industry-standard libraries which then makes upgrading impossible, and writing horrifically heavy wrappers around simple DB access that turns modern DB interaction into sludge for the purpose of solving problems that the previous product had and the current product doesn't. Take all that, and then insist that all new code do that as well. That's what I'm talking about.
inflatableDodo 7y ago
The term pattern is not dependent on things being proven through formal processes and anti-patterns are not defined as things that are not patterns. Anti-patterns can be patterns that have been proven through formal processes and the most successful of them tend to be.

stinos 7y ago

^ came here to post pretty much this; author seems to try to make a fairly good point, but the way it comes out is a bit strange and lacking foundation. It almost reads like the author had a bad experience online or in real life where he was told he used an anti-pattern where he actually wasn't and now extrapolates this. Don't know, just guessing here. Sure there might be a group of not too well-informed/skilled people religously believing patterns must be used whenever even remotely possible and not using patterns is bad, mkay, but I think (hope?) the group considering them as just another tool in the toolbox, used when appropriate but not otherwise, is larger.

EliRivers 7y ago
Sure there might be a group of... Several. I've not worked in such an environment myself, but I've had colleagues who have; workplaces where every design is permitted only to use concepts from the big book of patterns and any situation to which they are inappropriate is nonetheless solved (badly) with that big book of patterns.
- inflatableDodo 7y ago
  >workplaces where every design is permitted only to use concepts from the big book of patterns Can you name any of these workplaces?
  - EliRivers 7y ago
    The last chap who comes to mind I worked with who had previously worked in such a company was named Richard. Can't remember his last name, do remember I gave him a Wallace and Gromit moving toastrack as a leaving present when he went on to work for a flight sim company in the south west of England somewhere. I last worked with him when I was working for a UK offshoot of a US Defence company. This would have been somewhere around... six years ago, I guess. I suppose I could try to dig out his contact details and ask him, but I won't. So the short answer is no, I can't name that company. Got a feeling it was something involving printing, or imaging. I also cannot name any of the companies that any of my current colleagues have previously worked at. Is everyone else keeping track of where all their colleagues and ex-colleagues have worked? Wouldn't be surprised. I don't keep track of any of that. I'm not even on the facebook.

mikekchar 7y ago

In the original definition of "design pattern", it is a solution to a problem that has been generalised across multiple domains. In fact, a "pattern" is not a pattern unless it has been independently discovered by multiple different groups (I believe the original suggestion was 3). The point of a design pattern is not that it is superior it is that it is common. A design pattern is most assuredly not a best practice. In fact, it makes little sense to talk about a design pattern in isolation. It is a solution in a context. In some contexts it is appropriate and other contexts it is not appropriate. Design patterns used to have large preambles discussing the contexts where they were appropriate and where they were not. The point about an anti-pattern is that it is surprising. It must be a common approach that looks like it should work, but it doesn't. It is definitely not a "bad practice", or an "I don't like that" practice, or even an "inappropriately applied pattern". It's a surprising result that you should be aware of that tends to catch people frequently. Here is the first reference I know about discussing design patterns in software: https://c2.com/doc/oopsla87.html https://c2.com/doc/oopsla87.html (Yes, the "87" refers to "1987"). People who have only read about design patterns in the last decade or two are almost certainly missing the original point (as seems to be sadly common with these kinds of things).

sitkack 7y ago
To me, antipatterns are common modes of failure. Take for example a load balancer that is configured to send traffic to the fastest server at the time. Makes sense, if a server is fast it has more available capacity to handle requests. But when the front end code fails the server short circuits, skipping all the expensive code as it unwinds the stack and returns a 5XX error, the load balancer that just sends to the fastest now sends ALL traffic to the failing node. The antipattern is a feedback loop that is not measuring the right thing. In this case, they should be timing _successful_ calls to the front end.