3 ms·

Agreed. I hope nobody learns this pattern and looks for a project to inject it into. Design patterns should generally be avoided unless there's an obvious need

Agreed. I hope nobody learns this pattern and looks for a project to inject it into. Design patterns should generally be avoided unless there's an obvious need for them where they simplify your project. In my experience, it is incredibly rare. For the benefit of mankind, this is something that I think needs to be made clear with every discussion about design patterns.

ivan_gammel 9y ago
"Should be generally avoided" in favour of what? Each well-known pattern has its own applicability and use cases, which have been analyzed and described very well. I wonder, what makes you think, that all of it should be dismissed?
- turk184 9y ago
  Go learn Clojure or any LISP language and solve some problems using it. Watch the videos by Neal Ford and Rich Hickey. Think about your data. Then come back and reflect on it.
- flavio81 9y ago
  >Each well-known pattern has its own applicability and use cases, which have been analyzed and described very well. I wonder, what makes you think, that all of it should be dismissed? The GoF Design Patterns appeared after the GoF observed that these patterns happened in some C++ code, and thus they decided to formalize them and document them. All fine. The question is why did these patterns appear? Because programmers need to overcome the shortcomings of whatever programming language they are using. Other languages don't have the shortcomings of C++ or Java, thus, many of the GoF patterns simply don't apply or aren't needed. Another topic is that the patterns force the person to behave as a compiler; that is, to manually create abstractions that should be supported by the language in the first place. Languages with metaprogramming, like the Lisp family of languages, avoid the burden of having to do this. You can just program the abstraction as a macro once, and then apply it repeatedly whenever you want, without having to write more lines of code.
  - bjpbakker 9y ago
    > Languages with metaprogramming, like the Lisp family of languages, avoid the burden of having to do this Using macros or higher order functions doesn’t make the concept of a pattern go away. In Lisp you also use adapters, factories, strategies and the like. They’re just simply functions rather than overly complicated objects. Since its only functions on data structures, chances on reuse are indeed much larger.
    - flavio81 9y ago
      >They’re just simply functions rather than overly complicated objects. And thus the pattern becomes almost invisible. Instead of having to fully apply it the java (or C++) way, that is, for example creating a separate class for each Strategy, etc.
      - bjpbakker 9y ago
        Exactly. My point was more that the OO patterns refer to general concepts, that are useful to be able to recognize without objects cluttering your view. I believe we're on the same page :)
      - ivan_gammel 9y ago
        Software design pattern is a mental and communication concept, which has nothing to do with compilers/languages/etc. Design phase happens before you start writing your code - you have to first think about how the system will work and what will be its internal structure, and that's the moment when patterns start working. Then, even in Java you don't have to call your class "SomethingStrategy": you may simply follow the pattern to correctly implement what happens to be a strategy or to explain the behavior of the component to your colleagues. When you have the common language based on pattern names, it's much easier to say: "Look, this is a Builder for data model, which offers convenient internal DSL", rather than explaining everything from scratch. Patterns are ubiquitous tool for developers, not an evil. The evil is incompetence, with which some people blindly apply various programming concepts in totally inappropriate ways (including design patterns, functional and parallel programming etc).

ivan_gammel 9y ago

"Should be generally avoided" in favour of what? Each well-known pattern has its own applicability and use cases, which have been analyzed and described very well. I wonder, what makes you think, that all of it should be dismissed?

turk184 9y ago
Go learn Clojure or any LISP language and solve some problems using it. Watch the videos by Neal Ford and Rich Hickey. Think about your data. Then come back and reflect on it.
flavio81 9y ago
>Each well-known pattern has its own applicability and use cases, which have been analyzed and described very well. I wonder, what makes you think, that all of it should be dismissed? The GoF Design Patterns appeared after the GoF observed that these patterns happened in some C++ code, and thus they decided to formalize them and document them. All fine. The question is why did these patterns appear? Because programmers need to overcome the shortcomings of whatever programming language they are using. Other languages don't have the shortcomings of C++ or Java, thus, many of the GoF patterns simply don't apply or aren't needed. Another topic is that the patterns force the person to behave as a compiler; that is, to manually create abstractions that should be supported by the language in the first place. Languages with metaprogramming, like the Lisp family of languages, avoid the burden of having to do this. You can just program the abstraction as a macro once, and then apply it repeatedly whenever you want, without having to write more lines of code.
- bjpbakker 9y ago
  > Languages with metaprogramming, like the Lisp family of languages, avoid the burden of having to do this Using macros or higher order functions doesn’t make the concept of a pattern go away. In Lisp you also use adapters, factories, strategies and the like. They’re just simply functions rather than overly complicated objects. Since its only functions on data structures, chances on reuse are indeed much larger.
  - flavio81 9y ago
    >They’re just simply functions rather than overly complicated objects. And thus the pattern becomes almost invisible. Instead of having to fully apply it the java (or C++) way, that is, for example creating a separate class for each Strategy, etc.
    - bjpbakker 9y ago
      Exactly. My point was more that the OO patterns refer to general concepts, that are useful to be able to recognize without objects cluttering your view. I believe we're on the same page :)
    - ivan_gammel 9y ago
      Software design pattern is a mental and communication concept, which has nothing to do with compilers/languages/etc. Design phase happens before you start writing your code - you have to first think about how the system will work and what will be its internal structure, and that's the moment when patterns start working. Then, even in Java you don't have to call your class "SomethingStrategy": you may simply follow the pattern to correctly implement what happens to be a strategy or to explain the behavior of the component to your colleagues. When you have the common language based on pattern names, it's much easier to say: "Look, this is a Builder for data model, which offers convenient internal DSL", rather than explaining everything from scratch. Patterns are ubiquitous tool for developers, not an evil. The evil is incompetence, with which some people blindly apply various programming concepts in totally inappropriate ways (including design patterns, functional and parallel programming etc).