> People latched onto Design Patterns like that were tablets from God whereas the book was better thought of as giving a taxonomy to existing practices (and not even best practices.) Different subsets of their patterns work better in different languages, and it is pointless to force a specific pattern into a design where it doesn't fit naturally.
> I think it is useful to say "This design could be thought of as a delegate" when explaining your code, but saying "We need a delegate design pattern here" is needlessly prescriptive.
1000% this. The authors of the book describe it as a catalog of existing solutions to be applied appropriately given specific criteria, not as a panacea to all engineering problems. I've worked with a few architectural prescriptivists who shoehorned everything into a GoF Design Pattern - and amusingly enough none of them had actually read it and so could only name the common ones like Repository, Factory, or Singleton. Everything that wasn't one of these was just a Facade as far as they were concerned. This definitely worked but it left much to be desired once you started venturing out of rote CRUD territory.
On the other hand I had one Team Lead that shunned such tradition and purposefully mashed several things I'd written (Facotries, Repositories, and a Service that encapsulated everything) into a single giant "Helper" class destroying any abstraction or separation of concerns in the process. I guess it made little difference because that team never wrote unit tests but it wasn't good design by any stretch.
I digress but the idea is thus: some things in our field are common and timeless. It's helpful to give them names and to understand what the historical pain points are. It's not helpful to use them as a whooping stick.
> I think it is useful to say "This design could be thought of as a delegate" when explaining your code, but saying "We need a delegate design pattern here" is needlessly prescriptive.
1000% this. The authors of the book describe it as a catalog of existing solutions to be applied appropriately given specific criteria, not as a panacea to all engineering problems. I've worked with a few architectural prescriptivists who shoehorned everything into a GoF Design Pattern - and amusingly enough none of them had actually read it and so could only name the common ones like Repository, Factory, or Singleton. Everything that wasn't one of these was just a Facade as far as they were concerned. This definitely worked but it left much to be desired once you started venturing out of rote CRUD territory.
On the other hand I had one Team Lead that shunned such tradition and purposefully mashed several things I'd written (Facotries, Repositories, and a Service that encapsulated everything) into a single giant "Helper" class destroying any abstraction or separation of concerns in the process. I guess it made little difference because that team never wrote unit tests but it wasn't good design by any stretch.
I digress but the idea is thus: some things in our field are common and timeless. It's helpful to give them names and to understand what the historical pain points are. It's not helpful to use them as a whooping stick.