3 ms·

> IMHO, the whole idea of "design patterns" is that they are a standardized way of doing stuff To disagree - Design patterns are a communication language. You

> IMHO, the whole idea of "design patterns" is that they are a standardized way of doing stuff To disagree - Design patterns are a communication language. You use them to talk about code; if you use them as strict recipes they become dogma, with all the problems that entails. Beyond that - most of the canonical design patterns are coping mechanisms for the limitations of pre-modern Java / strict OOP. You just plain don’t need them in a language like Ruby - IMO, mostly because of ‘yeild’. The “imprecise use” is a consequence of either trying to use an unnecessary design pattern, or trying too dogmatically to adhere to one.

berkes 1y ago
> communication language I very much agree. But that means when we both say "decorator pattern", we must mean the same. The thing that in the Ruby community is a "Decorator" isn't a "decorator pattern". It's not following the details, but also not even meant for the use-cases or to solve limitations of ruby or strict OOP. It's simply not a "decorator" that we both think of (or would google, or read in e.g. GoF). It's something entirely different. In ruby/Rails (draper gem, most notably), they happen to use the word "Decorator" for a system that makes "view helpers" OOP rather than the normal rails way of a large bucket of random global helper-functions. I've had this conversation that shows the problem: - Me: If we'd use the decorator pattern, we could easily tame that large clumsy tree of subclasses in our authorization logic and make it much easier testable and understandable. - Wat? Decorators? But our authn has nothing to do with views! Why would we want to pull views-logic into our authn layer? So, by using the term wrong, at least N=1 shows how the "communication language" of Design PAtterns fails.

3 ms·

> IMHO, the whole idea of "design patterns" is that they are a standardized way of doing stuff To disagree - Design patterns are a communication language. You

by RangerScience 1y ago

berkes 1y ago
> communication language I very much agree. But that means when we both say "decorator pattern", we must mean the same. The thing that in the Ruby community is a "Decorator" isn't a "decorator pattern". It's not following the details, but also not even meant for the use-cases or to solve limitations of ruby or strict OOP. It's simply not a "decorator" that we both think of (or would google, or read in e.g. GoF). It's something entirely different. In ruby/Rails (draper gem, most notably), they happen to use the word "Decorator" for a system that makes "view helpers" OOP rather than the normal rails way of a large bucket of random global helper-functions. I've had this conversation that shows the problem: - Me: If we'd use the decorator pattern, we could easily tame that large clumsy tree of subclasses in our authorization logic and make it much easier testable and understandable. - Wat? Decorators? But our authn has nothing to do with views! Why would we want to pull views-logic into our authn layer? So, by using the term wrong, at least N=1 shows how the "communication language" of Design PAtterns fails.