3 ms·

"Maybe a better name for it would be "very global variable"." The better name for it already exists: it is the Singleton pattern, because OOP software develope

by sha90 17y ago

"Maybe a better name for it would be "very global variable"." The better name for it already exists: it is the Singleton pattern, because OOP software developers already understand this concept. You don't need to invent new names, this is why patterns exist. Also note that whether or not you use the "Singleton" mixin in Ruby, you are still using the Singleton pattern whenever you define a class with no constructor. Yes, you can do this without "include Singleton"; no, this does not mean you're magically using some new concept nobody's thought of before. You're still using Singletons. * The blog post doesn't use any patterns at all. Given that there are no code examples or suggestions, I don't see how you came to this conclusion. The blog post never tells you how to use patterns, it tells you why you use patterns. Where does it advise you to "pick up components and use them to assemble complete programs"? * Java did not exist when GoF wrote Design Patterns, so it clearly was not addressing any weaknesses of that language. Your point is DOA and you seem to be pulling this out of your ass. But, to elaborate: GoF isn't describing ways to patch any languages, it's describing ways to attack software problems. The idea of using a Strategy pattern (for instance) is universal among any programming language, it has absolutely nothing to do with code. So is using a factory method. Ever used `ActiveRecord.build` or 'create_with_...'? That's a factory method. The same concept applies with adapters, facades, et al. How you implement the pattern is completely irrelevant to the entire book. You could do it with dynamic dispatch or classes, the book doesn't define the patterns by their implementations. The point is you're using them. Pretending you're not is some kind of childish posturing so you can tell yourself you're "not doing anymore Java". I'm sorry you experienced your Java nightmares, but design patterns have nothing to do with that language.

tptacek 17y ago
How do you even write an paragraph about "whether or not" you'd use the "Singleton" mixin in Ruby? That's the point of this argument. You don't use it. Ever. There is absolutely no reason to use "Singleton" mixins in a language that already represents "classes" as objects. Similarly, you don't write "Strategy" code in a language that has first-class functions, and you don't write "Factory" code in a language that in which classes are first-class objects like everything else. You don't need a "Command" pattern in a language with closures and lambdas. And you don't need an "Adapter", "Facade", "Bridge" or "Proxy" in a language where function calls are already messages. You would have to deliberately write a book with no truth in it whatsoever to come up with a list of "patterns" that have no applicability at all. The Gang of Four didn't do that. It's an interesting book with valid ideas. But the approach of constructing programs out of "patterns" has been discredited, particularly and on account of the case where people use the Gang of Four's patterns as their template. Incidentally, you think I'm blazing new trails of ignorance here, but I am very late to the party with these comments, which I've mostly shoplifted from much smarter developers. Here's one such comment, from a (probably) better developer and (definitely) better writer than me. Tell me what you think of it: This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.
- sha90 17y ago
  You don't "write a paragraph", you use a word. In fact, the point of patterns is to save you from writing a paragraph. Again, not to repeat the entire blog or anything, but that's why the words exist. # This is a singleton class class MyClass class << self private :new def instance; @instance ||= new end end end Without looking at the methods or even the implementation I now know not to try to call `MyClass.new` because it's defined as a Singleton class. Simple. No paragraph necessary. You would need a paragraph if you didn't write this simple word. And guess what? I just used the Singleton pattern.
  - deleted 17y ago
    [deleted]
  - tptacek 17y ago
    Same fallacious argument: that when you do something that can be described by a design pattern, you're doing pattern-oriented software design. Same straw man argument: that anybody who points out that the GoF patterns are 'considered harmful' is arguing against concise, regular descriptions of design constructs. What's your point? The GoF patterns already lead you astray; just a few moments ago, upthread, you had to waste cycles considering whether to use a library to implement a "singleton pattern". The endpoint of this thinking is the SOAP4R code. Design patterns are code smells. I have good news for you. You're working in a modern language. You don't need to think about patterns. You don't need to spend even 15 seconds up front thinking about how you might decompose your problem into "Proxies" and "Factories". You can get to work right now on your problem domain. Because you're in a modern language, when, down the road, you discover that you need, say, to move a component into its own address space to collect calls and cache them, Ruby already gives you a "Proxy" construct. It's "method_missing" and it's idiomatic to the language. You will not need to dramatically alter your architecture to remote the method calls to a cache process; you'll just change the name of the class you call, from ExpensiveCollection to CachedExpensiveCollection, which will be about 15 lines of code long. And so there's another problem with using the names that OOPSLA dorks came up with 15 years ago. You're fighting the language's own idioms. Ruby doesn't want you to think in terms of "singletons" and "factories" and "commands". It wants you to know how closures work, and how messages are different from simple function calls. Another good article to read is that post by Wil Shipley about not writing too much code up front. Someone else can find the URL for you.

by sha90 17y ago

tptacek 17y ago

How do you even write an paragraph about "whether or not" you'd use the "Singleton" mixin in Ruby? That's the point of this argument. You don't use it. Ever. There is absolutely no reason to use "Singleton" mixins in a language that already represents "classes" as objects. Similarly, you don't write "Strategy" code in a language that has first-class functions, and you don't write "Factory" code in a language that in which classes are first-class objects like everything else. You don't need a "Command" pattern in a language with closures and lambdas. And you don't need an "Adapter", "Facade", "Bridge" or "Proxy" in a language where function calls are already messages. You would have to deliberately write a book with no truth in it whatsoever to come up with a list of "patterns" that have no applicability at all. The Gang of Four didn't do that. It's an interesting book with valid ideas. But the approach of constructing programs out of "patterns" has been discredited, particularly and on account of the case where people use the Gang of Four's patterns as their template. Incidentally, you think I'm blazing new trails of ignorance here, but I am very late to the party with these comments, which I've mostly shoplifted from much smarter developers. Here's one such comment, from a (probably) better developer and (definitely) better writer than me. Tell me what you think of it: This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

sha90 17y ago
You don't "write a paragraph", you use a word. In fact, the point of patterns is to save you from writing a paragraph. Again, not to repeat the entire blog or anything, but that's why the words exist. # This is a singleton class class MyClass class << self private :new def instance; @instance ||= new end end end Without looking at the methods or even the implementation I now know not to try to call `MyClass.new` because it's defined as a Singleton class. Simple. No paragraph necessary. You would need a paragraph if you didn't write this simple word. And guess what? I just used the Singleton pattern.
- deleted 17y ago
  [deleted]
- tptacek 17y ago
  Same fallacious argument: that when you do something that can be described by a design pattern, you're doing pattern-oriented software design. Same straw man argument: that anybody who points out that the GoF patterns are 'considered harmful' is arguing against concise, regular descriptions of design constructs. What's your point? The GoF patterns already lead you astray; just a few moments ago, upthread, you had to waste cycles considering whether to use a library to implement a "singleton pattern". The endpoint of this thinking is the SOAP4R code. Design patterns are code smells. I have good news for you. You're working in a modern language. You don't need to think about patterns. You don't need to spend even 15 seconds up front thinking about how you might decompose your problem into "Proxies" and "Factories". You can get to work right now on your problem domain. Because you're in a modern language, when, down the road, you discover that you need, say, to move a component into its own address space to collect calls and cache them, Ruby already gives you a "Proxy" construct. It's "method_missing" and it's idiomatic to the language. You will not need to dramatically alter your architecture to remote the method calls to a cache process; you'll just change the name of the class you call, from ExpensiveCollection to CachedExpensiveCollection, which will be about 15 lines of code long. And so there's another problem with using the names that OOPSLA dorks came up with 15 years ago. You're fighting the language's own idioms. Ruby doesn't want you to think in terms of "singletons" and "factories" and "commands". It wants you to know how closures work, and how messages are different from simple function calls. Another good article to read is that post by Wil Shipley about not writing too much code up front. Someone else can find the URL for you.