4 ms·

The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Or direct expressions of those concep

The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Or direct expressions of those concepts? Communicating intent through a common language is all and good, but then why that language isn't formally encoded in the compiler? > Is the language even missing anything at all? This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem.

geezerjay 9y ago
> The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Because they add or take nothing from the language. Arguing for the needless addition of these keywords makes as much sense as arguing in favour of camelCase or polish notation or "m_" and "s_" prefixes. They add nothing to the language, they are redundant and they are used to convey meaning alone. Therefore, what problem would be solved by adding useless keywords to a language, particularly when those making these claims come from a point of ignorance and lack of experience? > This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem. This makes no sense at all. Rather straigh-forward applications of polymorphism don't vanish if you call them by different names.
- loup-vaillant 9y ago
  Keywords are of course secondary. Did you miss the "or direct expressions of those concepts" part? I was implying the existence of some boilerplate reducing syntax behind them. With the right features, most patterns vanish. For instance: // C++98 class Adder { public: Adder(int inc) : _inc(inc) {} int const operator+(int n) { return n + _inc; } private: int _inc; }; // C++11 std::function(int(int)) adder(int inc) { return [=](int n) { return x + n; }; } (* Ocaml *) let adder inc n = inc + n -- Haskell adder inc n = inc + n Assuming currying is a good fit for your problem, you probably don't want to bother with factories, if you can use a language that supports currying directly. Same goes for other patterns: whichever you need suggest what language features you want. Or you could be content with repeating the same kind of code over and over, but I'm not going to accuse you of such obvious stupidity.
  - geezerjay 9y ago
    > With the right features, most patterns vanish. For instance: The thing is they don't. For example, a function pointer does not fill the need that strategy patterns fill. You look at a function pointer and you have no idea where and how and why it is supposed to be used, there is no type constraint, and there isn't even any way to track where how many different instances there are. A function pointer alone says nothing. Yet, specifying a common interface does, as well as implementing any concrete strategy. That's the whole point of using patterns. Furthermore, design patterns help clarify technical discussions as they communicate clear concepts as well as solutions to particular problems they solve. You get a clear idea of how a data access module is designed if the designer states that he used active records or repositories, and if classes are named appropriately you can already form a clear mental model of what to expect and, more importantly, what you will can or may need to do to fix a bug or implement a feature.
    - loup-vaillant 9y ago
      Who ever said "the right features" were limited to function pointers? Who ever even talked about function pointers? My example didn't even use function pointers! Are your imagination so limited that you cannot think of language features that would reduce the need for any specific pattern? I just showed you one, dammit! Let's step back a little: > 9 out of 10 patterns are nothing more than specific uses of inheritance and polymorphism. Of course, inheritance and polymorphism are the only thing Java has! Or had, back in 1995. Hammer & nail. There are other ways of expressing those patterns, other ways of solving the same problems that do not require those patterns at all. You just need to wake the fuck up and realise OOP is not the only game in town. > design patterns help clarify technical discussions as they communicate clear concepts as well as solutions to particular problems they solve. I have yet to witness a single instance of that in my job, and I've seen loads. On the contrary, naming patterns often clouds the underlying concepts. A pet peeve of mine is the Singleton. It's overused for sure, but that also makes it one of the most widely understood patterns. Yet few seem to realise that singletons are nothing more than global variables with a couple bells and whistles. And since the thing is not called "global variable", it doesn't trigger the appropriate mental warnings. What good are pattern names when programmers can't think clearly to begin with? It's not just the conversations. Every time I saw a pattern name in real code, I could find a simpler way. I also saw misapplied patterns, like factories that actually were memory pools. Whoever did that didn't know what they were talking about, and patterns didn't save them.

geezerjay 9y ago

> The point remain: why the average OOP languages does not have any "strategy", "command", "factory", or "observer" keyword? Because they add or take nothing from the language. Arguing for the needless addition of these keywords makes as much sense as arguing in favour of camelCase or polish notation or "m_" and "s_" prefixes. They add nothing to the language, they are redundant and they are used to convey meaning alone. Therefore, what problem would be solved by adding useless keywords to a language, particularly when those making these claims come from a point of ignorance and lack of experience? > This should be easily measured by the heaps and heaps of similar looking code that have no direct bearing with the actual problem. This makes no sense at all. Rather straigh-forward applications of polymorphism don't vanish if you call them by different names.

loup-vaillant 9y ago
Keywords are of course secondary. Did you miss the "or direct expressions of those concepts" part? I was implying the existence of some boilerplate reducing syntax behind them. With the right features, most patterns vanish. For instance: // C++98 class Adder { public: Adder(int inc) : _inc(inc) {} int const operator+(int n) { return n + _inc; } private: int _inc; }; // C++11 std::function(int(int)) adder(int inc) { return [=](int n) { return x + n; }; } (* Ocaml *) let adder inc n = inc + n -- Haskell adder inc n = inc + n Assuming currying is a good fit for your problem, you probably don't want to bother with factories, if you can use a language that supports currying directly. Same goes for other patterns: whichever you need suggest what language features you want. Or you could be content with repeating the same kind of code over and over, but I'm not going to accuse you of such obvious stupidity.
- geezerjay 9y ago
  > With the right features, most patterns vanish. For instance: The thing is they don't. For example, a function pointer does not fill the need that strategy patterns fill. You look at a function pointer and you have no idea where and how and why it is supposed to be used, there is no type constraint, and there isn't even any way to track where how many different instances there are. A function pointer alone says nothing. Yet, specifying a common interface does, as well as implementing any concrete strategy. That's the whole point of using patterns. Furthermore, design patterns help clarify technical discussions as they communicate clear concepts as well as solutions to particular problems they solve. You get a clear idea of how a data access module is designed if the designer states that he used active records or repositories, and if classes are named appropriately you can already form a clear mental model of what to expect and, more importantly, what you will can or may need to do to fix a bug or implement a feature.
  - loup-vaillant 9y ago
    Who ever said "the right features" were limited to function pointers? Who ever even talked about function pointers? My example didn't even use function pointers! Are your imagination so limited that you cannot think of language features that would reduce the need for any specific pattern? I just showed you one, dammit! Let's step back a little: > 9 out of 10 patterns are nothing more than specific uses of inheritance and polymorphism. Of course, inheritance and polymorphism are the only thing Java has! Or had, back in 1995. Hammer & nail. There are other ways of expressing those patterns, other ways of solving the same problems that do not require those patterns at all. You just need to wake the fuck up and realise OOP is not the only game in town. > design patterns help clarify technical discussions as they communicate clear concepts as well as solutions to particular problems they solve. I have yet to witness a single instance of that in my job, and I've seen loads. On the contrary, naming patterns often clouds the underlying concepts. A pet peeve of mine is the Singleton. It's overused for sure, but that also makes it one of the most widely understood patterns. Yet few seem to realise that singletons are nothing more than global variables with a couple bells and whistles. And since the thing is not called "global variable", it doesn't trigger the appropriate mental warnings. What good are pattern names when programmers can't think clearly to begin with? It's not just the conversations. Every time I saw a pattern name in real code, I could find a simpler way. I also saw misapplied patterns, like factories that actually were memory pools. Whoever did that didn't know what they were talking about, and patterns didn't save them.