4 ms·
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 a
by 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 agoSame 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.