4 ms·

I can't help but feel that this article sorta has the surface explanation of design patterns kinda right, but missing the essntial properties. Design patterns

I can't help but feel that this article sorta has the surface explanation of design patterns kinda right, but missing the essntial properties. Design patterns are solutions to recurring problems, but it's important to note that they are not the only solutions, and also that the "commonly recurring problems" are highly context dependent. Most of the OOP problems go away if you use more flexible programming languages or paradigms. New meta-patterns like DCI also invalidate the "recurring problems." Thus, the critical thing to recognize is that the expression "commonly recurring problems" is a trap, in that it is easy to assume that it is normal or expected for those problems to occur, when in actuality they occur as a consequence of large architecture decisions that can and perhaps should be made in such a way as to eliminate those problems outright rather than solve them. None of the aforementioned invalidates the concept of design patterns, however I feel it is difficult to say they are "just tools" as if it's perfectly reasonable to expect to have to use them on a regular basis as if programmers have no say in the matter of whether the need for those tools will or won't apply.

ExpiredLink 15y ago
> Most of the OOP problems go away if you use more flexible programming languages or paradigms. Spare us the myth. This isn't reddit.
- raganwald 15y ago
  Ironically, your comment is rather reditesque in that it piles abuse upon my comment without actually providing an argument against it. Perhaps you have something specific to share about why that or any other point is wrong? Perhaps an interesting viewpoint on myths and how they take hold?
  - true_religion 15y ago
    One myth I can think of is... most people believe that current design patterns originated in Java, or if not Java then C. This is primarily because of the languages books like Gang of Four use to illustrate design patterns. In reality however, most design patterns date back to Smalltalk which (ignoring multiple-inheritance for the moment), provides the most flexible and dynamic representation of objects that I've seen to date. ---- Another myth is that design patterns were invented. The the Gang of Four can be quoted as saying they merely are documenting patterns that will naturally occur in the course of writing code. If you use run-time-binding to determine an objects inteplementation, then congratulations you have Inversion of Control whether you want to call it that or not. The whole purpose of design patterns is to give us a common language so we don't have to describe our code, but can simply call it by name.
    - raganwald 15y ago
      I agree with what you've said here. I actually use ST to illustrate the relationship between patterns and languages. "Fluent Interface" is the name of a pattern wherein methods that are executed for their side-effects return the receiver, and callers then chain methods to a single receiver. This encourages writing many small methods while keeping code clear. It is not necessary in ST, because ST's syntax includes the semicolon operator for cascading messages to a single receiver. In effect, the pattern is "baked into the language."
    - ExpiredLink 15y ago
      > Another myth is that design patterns were invented. Patterns are detected - abstracted from what experienced people usually do in certain circumstances.
- route66 15y ago
  http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ illustrates the role of design patterns in dynamic languages: some are less important, others stay. But you could come up with that for yourself by comparing the need for a visitor pattern in, say, Java and Python respectively its implementation in both. [EDIT] Of course other programming paradigms can develop other patterns, if they are confronted with problems they cannot solve from the outset. That was more raganwald's point.
  - ExpiredLink 15y ago
    > Of course other programming paradigms can develop other patterns Of course, that's the point of patterns.
mistercow 15y ago
> Most of the OOP problems go away if you use more flexible programming languages or paradigms. This is exactly right. Even basic support for first-class functions makes a huge difference. There have been occasional posts around about classic design patterns in JavaScript, and the overwhelming feeling you get when you see most of the implementations is "Yes, but... why?"

ExpiredLink 15y ago

> Most of the OOP problems go away if you use more flexible programming languages or paradigms. Spare us the myth. This isn't reddit.

raganwald 15y ago
Ironically, your comment is rather reditesque in that it piles abuse upon my comment without actually providing an argument against it. Perhaps you have something specific to share about why that or any other point is wrong? Perhaps an interesting viewpoint on myths and how they take hold?
- true_religion 15y ago
  One myth I can think of is... most people believe that current design patterns originated in Java, or if not Java then C. This is primarily because of the languages books like Gang of Four use to illustrate design patterns. In reality however, most design patterns date back to Smalltalk which (ignoring multiple-inheritance for the moment), provides the most flexible and dynamic representation of objects that I've seen to date. ---- Another myth is that design patterns were invented. The the Gang of Four can be quoted as saying they merely are documenting patterns that will naturally occur in the course of writing code. If you use run-time-binding to determine an objects inteplementation, then congratulations you have Inversion of Control whether you want to call it that or not. The whole purpose of design patterns is to give us a common language so we don't have to describe our code, but can simply call it by name.
  - raganwald 15y ago
    I agree with what you've said here. I actually use ST to illustrate the relationship between patterns and languages. "Fluent Interface" is the name of a pattern wherein methods that are executed for their side-effects return the receiver, and callers then chain methods to a single receiver. This encourages writing many small methods while keeping code clear. It is not necessary in ST, because ST's syntax includes the semicolon operator for cascading messages to a single receiver. In effect, the pattern is "baked into the language."
  - ExpiredLink 15y ago
    > Another myth is that design patterns were invented. Patterns are detected - abstracted from what experienced people usually do in certain circumstances.
route66 15y ago
http://norvig.com/design-patterns/ http://norvig.com/design-patterns/ illustrates the role of design patterns in dynamic languages: some are less important, others stay. But you could come up with that for yourself by comparing the need for a visitor pattern in, say, Java and Python respectively its implementation in both. [EDIT] Of course other programming paradigms can develop other patterns, if they are confronted with problems they cannot solve from the outset. That was more raganwald's point.
- ExpiredLink 15y ago
  > Of course other programming paradigms can develop other patterns Of course, that's the point of patterns.

mistercow 15y ago

> Most of the OOP problems go away if you use more flexible programming languages or paradigms. This is exactly right. Even basic support for first-class functions makes a huge difference. There have been occasional posts around about classic design patterns in JavaScript, and the overwhelming feeling you get when you see most of the implementations is "Yes, but... why?"