Design patterns do a good job of capturing some design decisions you'll need to make in your career. They represent a level of architectural knowledge that is o

Design patterns do a good job of capturing some design decisions you'll need to make in your career. They represent a level of architectural knowledge that is often poorly captured and communicated in our industry (slightly above language features, and below whole frameworks). Many people treated the book (either in good faith over-enthusiasm, or as a bad faith strawman) as a repository of 'good' code to cut and paste. Some of those people would end up working in a functional language and claiming they don't need design patterns because they're the same as having first class functions. This is just mistaking the implementation for the design motivation. And even then, tough luck, however clever your language. Monads? A design pattern. So, I will stress again: design patterns represent decisions you can make about your code, in a particular context. If you want to be able to supply or accept a different algorithm to make a decision, that's the strategy pattern. Maybe it's an object with an interface, maybe it's a function callback. The important bit is you decided to let users of your API supply their own policy to make a decision (instead of you just asking for a massive dictionary called 'options' or whatever). If you want to ensure that all calls to one subsystem happen to a single instance, that's the singleton pattern. Whether you enforce that with static calls or in your inversion of control container, you're still making the decision to instantiate it once and not have every callee set up its own version taking up its own resources (or maybe you are, it's a decision after all). I get somewhat agitated about this stuff, because people are raised to be very skeptical of design patterns. This means they go through their career building up all sorts of design knowledge, but rarely naming and sharing it at a useful level of granularity. That's a huge waste! But the saddest thing about the whole conversation was that the decision _not_ to use a particular design pattern is just as valid as the one to use it, and _even then_ it's still a superior approach because you can be explicit about what you're not doing in your code and why. Anyway, good luck in your career!