5 ms·

Effective C++ was an amazing book. I bought copies for the entire team out of my own pocket. The Gang of Four on the other hand was an unfortunate turn for th

Effective C++ was an amazing book. I bought copies for the entire team out of my own pocket. The Gang of Four on the other hand was an unfortunate turn for the industry. As you say we took it too seriously. In practice very few projects can benefit from the "Factory pattern", but I've seen it used in way too many projects to the detriment of readability. I worked in one source code base where you had to invoke 4 different factories spread across many different source files just to allocate one object.

mikrl 4y ago
Would you say the GoF are more descriptive than prescriptive? That is, not “do these to write good code” but “well written code looks like this”
- munificent 4y ago
  It is meta-prescriptive. It doesn't say, "Do this to make your code better." It says, "If you have this specific problem under these constraints, then this can help."
- black3r 4y ago
  definitely yes, I'd even go as far as to say they're just exemplary, meaning "well written code can look (for example) like this", but since they became "industry standards", they help your code be understood (either by other people, or by you when you eventually forget how/why you wrote it that way), which helps speed up code review and make it easier to maintain / refactor old code...
raspberry1337 4y ago
I am a newly employed engineer and I am assigned to learn Design patterns (the book and all) right as of today. Needless to day, I am very intrigued. Could you expand what you mean by too far, beyond over-applying the patterns?
- abraxas 4y ago
  It's that. Over applying patterns in the areas of the code that are unlikely to need the extensibility afforded by employing these patterns. The cost of using the patterns is that they add a level of indirection which later costs you and others some extra cognitive load. By and large though the GoF patterns are relevant today and when applied judiciously they do help to organize your code.
  - raspberry1337 4y ago
    Have these OO-patterns become less relevant or is it just that they were absolutely standard 20-30 years ago- so that they are old and less relevant only in the perspective of their previous dominance?
    - HeyLaughingBoy 4y ago
      A lot of is is that modern frameworks include a lot of those behaviors that required you to manually code the patterns back them. e.g., I can create a an ObservableCollection in C# with a single line of code, but in 1996 C++ I'd have to go to the trouble of building out an Observer pattern and it still wouldn't have all the features that IObservable does.
    - mch82 4y ago
      HeyLaughingBoy is right about patterns being built into frameworks we use today (can’t reply to that comment because it’s nested too deeply). Rails is an example. I’ve seen a number of talks and articles by DHH that emphasize patterns and talking with people who wrote patterns. Rails built those in (like “model view controller”). Libraries and frameworks weren’t publicly available 30 years ago. Certainly not for free. The patterns are still useful, it’s just that a library or framework is often more efficient than reimplementing a pattern from scratch.
- eddsh 4y ago
  Don't listen too closely to the issues people have with GoF and Design Patterns. Yes, they have their issues and an over-reliance is an issue. However as a junior engineer you should learn these things and come to this realization (or not) yourself! Also if your company does use these things, code standardization across the org is more important than the downfalls of overly complex patterns. I read these arguments instead of focusing on learning patterns and it just caused grief until I decided to learn the patterns.
munificent 4y ago
> As you say we took it too seriously. The real problem is that many people didn't actually read the book or, if they did, they only took part of it seriously. Each pattern chapter has a pretty long section that details when you should and should not use the pattern. The authors are very clear about understanding the context and not mis-applying patterns. But once it became popular (which happened because these patterns are quite useful), it got cargo culted and people started over-applying them because it sent a social signal that, "Hey, I must be a good developer because I know all these patterns." The software engineering world is a much better one today because of that book now that the pendulum has swung back some from the overshoot.
- codalan 4y ago
  It's amazing how many times I saw the Singleton pattern between 2000 - 2012 or so, and in almost every case, it degenerated into a global variable that was used by everything in a component or system. It would have been more apt to name it the Simpleton pattern, after most of their practitioners. This stuff started to go away w/ modern DI frameworks. In fact, I don't really see much of the GoF patterns anymore, particularly ones for managing the order of instantiation of objects. Everything in the C# world has been abstracted/libraried/APIed away. But I wouldn't be surprised if GoF patterns are still prevalent in C/C++/SmallTalk code.
feoren 4y ago
> In practice very few projects can benefit from the "Factory pattern" The factory pattern in C#: public IMeasuringDevice CreateMeasuringDevice(Func<IUnitConverter> unitConverterFactory) In TypeScript: function createMeasuringDevice(unitConverterFactory: () => UnitConverter): MeasuringDevice Very few projects can benefit from this!?

mikrl 4y ago

Would you say the GoF are more descriptive than prescriptive? That is, not “do these to write good code” but “well written code looks like this”

munificent 4y ago
It is meta-prescriptive. It doesn't say, "Do this to make your code better." It says, "If you have this specific problem under these constraints, then this can help."
black3r 4y ago
definitely yes, I'd even go as far as to say they're just exemplary, meaning "well written code can look (for example) like this", but since they became "industry standards", they help your code be understood (either by other people, or by you when you eventually forget how/why you wrote it that way), which helps speed up code review and make it easier to maintain / refactor old code...

raspberry1337 4y ago

I am a newly employed engineer and I am assigned to learn Design patterns (the book and all) right as of today. Needless to day, I am very intrigued. Could you expand what you mean by too far, beyond over-applying the patterns?

abraxas 4y ago
It's that. Over applying patterns in the areas of the code that are unlikely to need the extensibility afforded by employing these patterns. The cost of using the patterns is that they add a level of indirection which later costs you and others some extra cognitive load. By and large though the GoF patterns are relevant today and when applied judiciously they do help to organize your code.
- raspberry1337 4y ago
  Have these OO-patterns become less relevant or is it just that they were absolutely standard 20-30 years ago- so that they are old and less relevant only in the perspective of their previous dominance?
  - HeyLaughingBoy 4y ago
    A lot of is is that modern frameworks include a lot of those behaviors that required you to manually code the patterns back them. e.g., I can create a an ObservableCollection in C# with a single line of code, but in 1996 C++ I'd have to go to the trouble of building out an Observer pattern and it still wouldn't have all the features that IObservable does.
  - mch82 4y ago
    HeyLaughingBoy is right about patterns being built into frameworks we use today (can’t reply to that comment because it’s nested too deeply). Rails is an example. I’ve seen a number of talks and articles by DHH that emphasize patterns and talking with people who wrote patterns. Rails built those in (like “model view controller”). Libraries and frameworks weren’t publicly available 30 years ago. Certainly not for free. The patterns are still useful, it’s just that a library or framework is often more efficient than reimplementing a pattern from scratch.
eddsh 4y ago
Don't listen too closely to the issues people have with GoF and Design Patterns. Yes, they have their issues and an over-reliance is an issue. However as a junior engineer you should learn these things and come to this realization (or not) yourself! Also if your company does use these things, code standardization across the org is more important than the downfalls of overly complex patterns. I read these arguments instead of focusing on learning patterns and it just caused grief until I decided to learn the patterns.

munificent 4y ago

> As you say we took it too seriously. The real problem is that many people didn't actually read the book or, if they did, they only took part of it seriously. Each pattern chapter has a pretty long section that details when you should and should not use the pattern. The authors are very clear about understanding the context and not mis-applying patterns. But once it became popular (which happened because these patterns are quite useful), it got cargo culted and people started over-applying them because it sent a social signal that, "Hey, I must be a good developer because I know all these patterns." The software engineering world is a much better one today because of that book now that the pendulum has swung back some from the overshoot.

codalan 4y ago
It's amazing how many times I saw the Singleton pattern between 2000 - 2012 or so, and in almost every case, it degenerated into a global variable that was used by everything in a component or system. It would have been more apt to name it the Simpleton pattern, after most of their practitioners. This stuff started to go away w/ modern DI frameworks. In fact, I don't really see much of the GoF patterns anymore, particularly ones for managing the order of instantiation of objects. Everything in the C# world has been abstracted/libraried/APIed away. But I wouldn't be surprised if GoF patterns are still prevalent in C/C++/SmallTalk code.

feoren 4y ago

> In practice very few projects can benefit from the "Factory pattern" The factory pattern in C#: public IMeasuringDevice CreateMeasuringDevice(Func<IUnitConverter> unitConverterFactory) In TypeScript: function createMeasuringDevice(unitConverterFactory: () => UnitConverter): MeasuringDevice Very few projects can benefit from this!?