3 ms·

I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. For instance, MVC is a very popu

by shubb 10y ago

I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program. They can also be useful in a context where not everyone in the team is used to writing code in a disciplined way - like coding standards and ideas like YAGNI, they can give an objective set of standards at code review. Adopting a few of these strategies in a code base provides a standard people can refer to about what goes where. Where the question is whether James should have stuck this database code in the class that renders the web page, being able to point to a well documented strategy and say "that code doesn't go there because we're doing that" can be better than excessive conflict. The author is right that if you have a common problem, you should probably be solving it with a library (preferably someone else's). However, often these libraries and frameworks are implementing the generic bits of the design pattern, and understanding that pattern gives you a shortcut to knowing how to use them well.

nsxwolf 10y ago
That's exactly right. The GoF patterns were identified from experience and then formalized, not created from whole cloth. Programmers that don't know anything about design patterns use many of them, often without realizing they are doing it. The GoF patterns give everyone a common vocabulary to reason about the patterns.
throwsincenotpc 10y ago
> For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program. The problem with MVC is that it lost any accurate meaning.If you tell me "my app is MVC", I vaguely understand it has a view, a controller and a model but it doesn't tell me if the controller sits between the view and the model or the view directly observes changes in the model. If you take a pattern like the Chain of Responsibility, or the Command pattern, the goals are clear because they are usually made of a single or at most 2 collaborators. MVC is sometimes a mix between the strategy and the observer, sometimes it isn't yet people still call that MVC.
- shubb 10y ago
  The major problem for me with MVC, is that people build complex applications on an MVC framework and then try to shoehorn various things that are definitely not views, models, or controllers, into the pattern. I've seen applications that control hardware where a class called 'model' twiddles bits on an interface port and then blocks until it sees some bits twiddled in response. Or where the 'controller' actually goes off for an hour to do heavy data processing (using the web servers thread pool as a job queuing system). In both these cases, those things should have been in descriptively named classes that accurately described what they did. In the latter case, trying to adhere to a pattern gave the application a strange architecture that could have unforeseen problems. I'm not sure if MVC is even the right pattern for a lot of modern web applications with a thick client or that describe a workflow. Often it feels like you are shoehorning there. However, I'd say these are cases of 'doing it wrong' that don't prove the overall approach bad. I picked MVC because everyone has heard of it.
  - mcbits 10y ago
    This is why I disagree with the shared language interpretation of design patterns. Once you slap "MVC" or any other name on some code, you'll constantly be second-guessing whether new code is violating the pattern. The goal is to produce working, efficient, secure, maintainable software, not to implement patterns. I think design pattern books would be more helpful if they deleted all the pattern names and just called the book "A collection of a-ha! moments in C++" or whatever. Readers could skim through the chapters every couple of months until they stop having a-ha! moments. The "patterns" may or may not emerge in the reader's code, depending on what works best for a specific project.
Arwill 10y ago
>I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. I've seen a big project with heavy emphasis on patterns, and it was a hell for new programmers. Take a month debugging 50 levels of method calls trough the facades and the framework, just to find code that does the business logic.
- deanCommie 10y ago
  Every tool it can be misused. Doesn't mean it doesn't have value.

by shubb 10y ago

nsxwolf 10y ago

That's exactly right. The GoF patterns were identified from experience and then formalized, not created from whole cloth. Programmers that don't know anything about design patterns use many of them, often without realizing they are doing it. The GoF patterns give everyone a common vocabulary to reason about the patterns.

throwsincenotpc 10y ago

> For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program. The problem with MVC is that it lost any accurate meaning.If you tell me "my app is MVC", I vaguely understand it has a view, a controller and a model but it doesn't tell me if the controller sits between the view and the model or the view directly observes changes in the model. If you take a pattern like the Chain of Responsibility, or the Command pattern, the goals are clear because they are usually made of a single or at most 2 collaborators. MVC is sometimes a mix between the strategy and the observer, sometimes it isn't yet people still call that MVC.

shubb 10y ago
The major problem for me with MVC, is that people build complex applications on an MVC framework and then try to shoehorn various things that are definitely not views, models, or controllers, into the pattern. I've seen applications that control hardware where a class called 'model' twiddles bits on an interface port and then blocks until it sees some bits twiddled in response. Or where the 'controller' actually goes off for an hour to do heavy data processing (using the web servers thread pool as a job queuing system). In both these cases, those things should have been in descriptively named classes that accurately described what they did. In the latter case, trying to adhere to a pattern gave the application a strange architecture that could have unforeseen problems. I'm not sure if MVC is even the right pattern for a lot of modern web applications with a thick client or that describe a workflow. Often it feels like you are shoehorning there. However, I'd say these are cases of 'doing it wrong' that don't prove the overall approach bad. I picked MVC because everyone has heard of it.
- mcbits 10y ago
  This is why I disagree with the shared language interpretation of design patterns. Once you slap "MVC" or any other name on some code, you'll constantly be second-guessing whether new code is violating the pattern. The goal is to produce working, efficient, secure, maintainable software, not to implement patterns. I think design pattern books would be more helpful if they deleted all the pattern names and just called the book "A collection of a-ha! moments in C++" or whatever. Readers could skim through the chapters every couple of months until they stop having a-ha! moments. The "patterns" may or may not emerge in the reader's code, depending on what works best for a specific project.

Arwill 10y ago

>I've always seen design patterns principally as a way of communicating what you are doing to other programmers who come later. I've seen a big project with heavy emphasis on patterns, and it was a hell for new programmers. Take a month debugging 50 levels of method calls trough the facades and the framework, just to find code that does the business logic.

deanCommie 10y ago
Every tool it can be misused. Doesn't mean it doesn't have value.