rss
11-28-2012, 07:39 PM
Design and programming patterns are wonderful ways of disseminating k**wledge. It’s immensely satisfying to bring solution to a tough problem by applying a perfect-fit pattern.
But success with pattern applications is like taking that first in**cent bump (http://wiki.answers.com/Q/How_much_of_cocaine_is_in_a_bump). You quickly want more of what made you feel this good. And buoyed by the high of a perfect fit, it’s easy to develop pattern vision where code, like Tetris shapes, become mere blocks for fitting into the pattern holes.
With this infliction, you will invariably drift away from the original intent of making specific and immediate pain go away. Where the perfect and legitimate fit will remove a thorn that’s obviously hurting the code right **w, the speculative fit pretends to do the same for future hurts.
**w that’s an ho**rable intention. A pinch of prevention over a pound of cure, right? Only, it rarely works out like that. Speculative pattern applications to avoid future, possible ails is a form of fortune telling. It’s the reason YAGNI (http://en.wikipedia.org/wiki/You_ain't_gonna_need_it) was coined.
The further down this rabbit hole you go, the farther away from practical improvement you’ll end up. Go deep e**ugh and the pattern vision turns into articles of faith. Inheritance is always bad, only composition can be our true savior! Only standalone command objects can give us the reusability this application needs!
Turning patterns into articles of faith takes them out of the realm of rational discussion. Code either adheres to the holy patterns or it doesn’t. If it does **t, the programmer must first repent, say his 25 rose-delegations, and then swear never to let an opportunity for a policy object extraction pass by him again!
The naming of many design principles supports this theological world view that patterns also at times inhibit. It’s obvious that you’re a sinner if you break The Law of Demeter (http://c2.com/cgi/wiki?LawOfDemeter) and of weak will if you forgo the Single Responsibility Principle (http://en.wikipedia.org/wiki/Single_responsibility_principle).
Patterns are best thought of like helpful guidelines and suggestions, **t laws, **t imperatives. It’s a written account of “hey, if you have this problem, you can try this thing to make it better”. Their core value is transforming some code to better code in a way that’s immediately obvious to the writer.
Evaluating such improvement is easy. You look at the code you had before applying the pattern and after it. Did it make the code simpler to understand? Clearer? Prettier? If you can’t easily see whether that’s so, you’ve been sold.
http://feeds.feedburner.com/~ff/37signals/beMH?d=yIl2AUoC8zA (http://feeds.feedburner.com/~ff/37signals/beMH?a=2jNVyzdAo7M:z5x3u6dPy54:yIl2AUoC8zA) http://feeds.feedburner.com/~ff/37signals/beMH?d=7Q72WNTAKBA (http://feeds.feedburner.com/~ff/37signals/beMH?a=2jNVyzdAo7M:z5x3u6dPy54:7Q72WNTAKBA)
http://feeds.feedburner.com/~r/37signals/beMH/~4/2jNVyzdAo7M
أكثر... (http://feedproxy.google.com/~r/37signals/beMH/~3/2jNVyzdAo7M/3341-pattern-vision)
But success with pattern applications is like taking that first in**cent bump (http://wiki.answers.com/Q/How_much_of_cocaine_is_in_a_bump). You quickly want more of what made you feel this good. And buoyed by the high of a perfect fit, it’s easy to develop pattern vision where code, like Tetris shapes, become mere blocks for fitting into the pattern holes.
With this infliction, you will invariably drift away from the original intent of making specific and immediate pain go away. Where the perfect and legitimate fit will remove a thorn that’s obviously hurting the code right **w, the speculative fit pretends to do the same for future hurts.
**w that’s an ho**rable intention. A pinch of prevention over a pound of cure, right? Only, it rarely works out like that. Speculative pattern applications to avoid future, possible ails is a form of fortune telling. It’s the reason YAGNI (http://en.wikipedia.org/wiki/You_ain't_gonna_need_it) was coined.
The further down this rabbit hole you go, the farther away from practical improvement you’ll end up. Go deep e**ugh and the pattern vision turns into articles of faith. Inheritance is always bad, only composition can be our true savior! Only standalone command objects can give us the reusability this application needs!
Turning patterns into articles of faith takes them out of the realm of rational discussion. Code either adheres to the holy patterns or it doesn’t. If it does **t, the programmer must first repent, say his 25 rose-delegations, and then swear never to let an opportunity for a policy object extraction pass by him again!
The naming of many design principles supports this theological world view that patterns also at times inhibit. It’s obvious that you’re a sinner if you break The Law of Demeter (http://c2.com/cgi/wiki?LawOfDemeter) and of weak will if you forgo the Single Responsibility Principle (http://en.wikipedia.org/wiki/Single_responsibility_principle).
Patterns are best thought of like helpful guidelines and suggestions, **t laws, **t imperatives. It’s a written account of “hey, if you have this problem, you can try this thing to make it better”. Their core value is transforming some code to better code in a way that’s immediately obvious to the writer.
Evaluating such improvement is easy. You look at the code you had before applying the pattern and after it. Did it make the code simpler to understand? Clearer? Prettier? If you can’t easily see whether that’s so, you’ve been sold.
http://feeds.feedburner.com/~ff/37signals/beMH?d=yIl2AUoC8zA (http://feeds.feedburner.com/~ff/37signals/beMH?a=2jNVyzdAo7M:z5x3u6dPy54:yIl2AUoC8zA) http://feeds.feedburner.com/~ff/37signals/beMH?d=7Q72WNTAKBA (http://feeds.feedburner.com/~ff/37signals/beMH?a=2jNVyzdAo7M:z5x3u6dPy54:7Q72WNTAKBA)
http://feeds.feedburner.com/~r/37signals/beMH/~4/2jNVyzdAo7M
أكثر... (http://feedproxy.google.com/~r/37signals/beMH/~3/2jNVyzdAo7M/3341-pattern-vision)