https://web.archive.org/web/20080327040226/http://www.codinghorror.com:80/blog/archives/000899.html
critique
https://web.archive.org/web/20040720013214/http://www.geocities.com/tablizer/prpats.htm#strategy from Richard Mansfield
from Dadgum
https://web.archive.org/web/20051214092027/http://plasmasturm.org:80/log/338/ Why do the design patterns people come up with such ridiculously elaborate conceptualisations of perfectly trivial ideas?
The term “Dependency Injection” has been popping up periodically in the feeds I read, and each discussion left me with a disconcerting sense of missing something vague, so I decided to address my ignorance.
I had already gotten myself up to speed with what Inversion of Control is a few days ago, because these two terms tend to show up together. But that was different, since merely reading the discussions gave me a gut understanding of the term that was sufficient to follow them. The definition just reinforced and reassured my comprehension. It’s a distinctive if prosaic concept.
With “Dependency Injection” however, the excercise was harder. Lots of explanation that didn’t seem to be making any particular point was all I could see. Where was the meat? I read and reread the definition, examined the flimsy code snippets carefully, stared at the nearly tautologic diagrams for roughly 10 minutes, trying to grasp the deeply profound idea but failing. It finally dawned on me, after investing much effort, that it was right there – only banal enough that it was obscured by the heaps of pontification. It turns out the concept is so trite I've used it more times than I can remember, without ever having thought of it as any kind of dinstinct idea. What the heck?
That explains the feeling of missing something vague. All the critical examination and lengthy discussion suggested profundity that simply does not exist. The impressive-sounding term is nothing but a thin cloud of vapour.
This is just another reminder that I should learn to trust my gut.
Car extends vehicle
https://web.archive.org/web/20060517045540/http://plasmasturm.org:80/log/340/ links to https://web.archive.org/web/20060623095820/http://c2.com:80/cgi/wiki?ReplaceConditionalWithPolymorphism
https://web.archive.org/web/20051220121453/http://www.martinfowler.com:80/articles/injection.html
books
Now if you want a really painful read, try Patterns of Software by Richard Gabriel. 200 pages of tedious speculation on the qualities of "good" software, which ultimately turns out to be the question of what constitutes objective beauty. He ends of up calling this thing "the quality without a name" and can only gesture at it with obscure utterances like "A system has this quality when it is at peace with itself, when it has no internal contradictions ... when it is true to its own inner forces".
https://archive.org/details/PatternsOfSoftware
youtube
[https://www.youtube.com/watch?v=v9ejT8FO-7I&list=PLrhzvIcii6GNjpARdnO4ueTUAVR9eMBpc strategy pattern by Christopher Okhravi
Steve Rowe
https://web.archive.org/web/20160316152818/http://blogs.msdn.com/b/steverowe/archive/2007/07/11/are-design-patterns-a-bad-idea.aspx responding to Jeff Atwood critique of DP at https://web.archive.org/web/20080327040226/http://www.codinghorror.com:80/blog/archives/000899.html
...Second, he's attacking the concept when it's really an implementation of the concept that deserves his criticism....
No true Scotsman fallacy. One way to make something unfalsifiable it refuse to define what you mean. "Software engineers" ever defines OOP as a struct where all the functions take the struct as their first parameter spawning a restricted global.
links
https://web.archive.org/web/20080316011001/http://norvig.com/design-patterns/ Peter Norvig
https://blog.plover.com/prog/johnson.html Johnson from(Go4) replies
https://pozorvlak.livejournal.com/94558.html and (https://archive.ph/MAgVn) links to https://astares.blogspot.com/2008/02/who-owns-language.html,(https://archive.ph/oJxs3) and
plerl slides design patterns The appearance of iterators in an object-oriented language appears to be inversely related to the power of the language's intrinsic control structures. Iterator classes are used for the sole purpose of enumerating the elements of an abstract collection class without revealing its implementation. We find that the availability of higher-order functions and function closures eliminates the need for these ad hoc iterator classes, in addition to providing the other benefits of "mostly functional programming". We examine a purely functional iteration protocol for the difficult task of comparing the collections of leaves on two non-isomorphic trees--the so-called "samefringe" problem--and find that its type signature requires recursive (cyclic) functional types. Although higher-order "member functions" and recursive (cyclic) functional types are unusual in object-oriented languages, they arise quite naturally and provide a satisfying programming style.
https://blog.plover.com/prog/design-patterns.html stuffing procedures into structs