What it was trying to be was misunderstood. Arguably, there were too few patterns and they were provided as a way to build software like LEGOs. I've read "A P

What it was trying to be was misunderstood. Arguably, there were too few patterns and they were provided as a way to build software like LEGOs. I've read "A Pattern Language: Towns, Buildings, Construction" which was the inspiration for the GoF book. That book had 253 patterns and they were written as "here are ways architects solve common problems". Pattern 148 - small work groups > When more than half a dozen people work in the same place, it is essential that they not be forced to work in one huge undifferentiated space, but that instead, they can divide their workspace up, and so form smaller groups. > In fact, people will feel oppressed, both when they are either working in an undifferentiated mass of workers and when they are forced to work in isolation. The small group achieves a nice balance between the one extreme in which there are so many people, that there is no opportunity for an intimate social structure to develop, and the other extreme in which there are so few, that the possibility of social groups does not occur at all. > ... > Break institutions into small, spatially identifiable work groups, with less than half a dozen people in each. Arrange these work groups so that each person is in at least partial view of the other members of his own group; and arrange several groups in such a way that they share a common entrance, food, office equipment, drinking fountains, bathrooms. > Lay the workgroups out with respect to each other so that the distances between groups is within the constraints of OFFICE CONNECTIONS (82), and give each group office space which leaves room to expand and to contract-FLEXIBLE OFFICE SPACE (146); provide a common area, either for the group itself or for several groups together or both —- COMMON AREA AT THE HEART (129). Treat each small work group, in every kind of industry and office, as a place of learning—MASTER AND APPRENTICES (83). Give it its own stair, directly to the street—OPEN STAIRS (158). Arrange the individual workspaces within the small work group according to HALF-PRIVATE OFFICE 152) and WORKSPACE ENCLOSURE (183) . . . . It's a not a dictate, but rather descriptive of "these are problems and ways people solved them" along with maintaining a unified vision of the design. The GoF book became prescriptive instead. People used the patterns in anticipation of the problems rather than because they had them. https://www.artima.com/articles/how-to-use-design-patterns https://www.artima.com/articles/how-to-use-design-patterns > Bill Venners: Is the value of patterns, then, that in the real world when I feel a particular kind of pain I'll be able to reach for a known solution? > Erich Gamma: This is definitely the way I'd recommend that people use patterns. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3. > Trying to use all the patterns is a bad thing, because you will end up with synthetic designs—speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution. --- The Patterns from GoF became the goal without understanding what a Pattern is. It's a way to hold complexity. A function call is a Pattern. Store volatile registers onto stack, put return address onto stack, put parameters onto stack, jump to new instruction, restore registers. That Pattern is now hidden inside of `foo(bar, qux)` and that hides a lot of the complexity for what is being done. But we don't come with the idea that to write a good program, you must use functions. Well, you should because they're likely complex enough to need them... but we use them when we need to manage that complexity. A phrase I used before was that the GoF isn't a cookbook but rather a bestiary of complexity. The problem is when people use Patterns in anticipation of complexity that isn't there. So when they're putting patterns in places, as a maintainer you see dark and (maybe) empty cages. Do you want to stick your hand in it to see if it will get bitten off? Don't have empty complexity cages. And when you do need the complexity cage, properly illuminate it with a clear description of what it is and what complexity it contains. (yes, I can rant about Patterns) https://c2.com/ppr/wiki/WikiPagesAboutWhatArePatterns/PatternLanguage.html https://c2.com/ppr/wiki/WikiPagesAboutWhatArePatterns/Patter... And one of the blog posts of yesteryear that influenced me - https://perl.plover.com/yak/design/ https://perl.plover.com/yak/design/