31–40 of 133 posts
To be fair, it is far from the only source of motivation to see programmers as (or turn them into) a fancy macro processor. Maybe that's one reason why shops where discussion orients heavily on design patterns often also seem to be places where Management Theory X [0] is on display.
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 eve…
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.
If you read Alexander's interviews in Stuart Brand's How Buildings Learn you'll see he's mostly concerned with how to connect people directly with the problems his buildings and urban planning are trying to solve. It's highly cultural. He rails against what he calls "magazine architecture" where buildings are designed mostly to photograph well, their inhabitants's problems with the buildings are an afterthought. Sounds familiar?
You can build an abstraction where a car as a particle for a thought experiment or where a car is 3d vehicle with a deformable chassis for crash simulation. Both can represent a vehicle to certain level of detail. The correctness of using each level of detail is very context sensitive.
To model a problem after a design pattern can have a lot of overhead, but it can objectively produce a working solution.
Now, if the design pattern is really a way to solve a problem in terms of constraints imposed by a type system or a language, once you add, change or remove those constraints the problem solving approach might stop making sense or being optimal.
for elem in collection:
This guy clearly doesn't understand the iterator pattern! J/K'ing. But he consciously chose to give the talk a "click bait" title, and the goat thing was a bit of hyperbole. Totally reasonable things to do, but know that you have to live with the backlash from that. All of that said, I agree with this core point that "we need to take a fresh look at Christopher Alexander". I plan to go out and get a copy of the patte…
(I would recommend reading or skimming through "A Pattern Language" first, to get a good idea of what Alexander's idea of a well-formed pattern is. It's also a really interesting book in its own right, especially if you have any interest in architecture.)
"The Gang-of-Four idea is to discover existing patterns of software development. Then program people to implement them habitually" Citation needed. GoF's intention was to give people a tool for thinking about architecture and sharing their experiences with others. If people are "programmed to implement them habitually", that's some manager's fantasy and neither in the letter or spirit of Design Patterns. It's be like…
As others have pointed out, the book is nice because it gave rise to a common language for describing patterns, and it's much easier to understand code someone else wrote if you can divine intentions from variable and class names.
This is what strongly-typed functional programming languages have been teaching and preaching and practising for years.
"The Gang-of-Four idea is to discover existing patterns of software development. Then program people to implement them habitually" Citation needed. GoF's intention was to give people a tool for thinking about architecture and sharing their experiences with others. If people are "programmed to implement them habitually", that's some manager's fantasy and neither in the letter or spirit of Design Patterns. It's be like…
The issue is that in a lot of shops design patterns have turned into a religion and not just a tool to help thinking. I've seen managers like that.
If you didn't implement 15 different design patterns in this or that code base that was "bad design", even if it unnecessarily made the code more complex.
I've seen iterators classes written when a simple for loop would have done the trick. I've seen chains of responsibility implemented when a basic switch statement would have been enough. Of course the code wasn't meant to be refactored in anyways. In fact complexity led to inability to refactor anything as nobody had a clue what went where ... and of course to manage all that bullshit we had to write tons of factories, because instantiating a single useful object now took 30 lines of code ...