On Sun, Nov 6, 2011 at 11:12 AM, Dennis Haupt <d.haup...@googlemail.com> wrote: > let me guess: you had some classes that were used more than they should > have been because they were the best match and introducing a better one > would have taken more time - and since they could do so much, they were > just used at more and more places and in the end, they became god > classes which infested everything?
I generally refactored them into submission before they reached "god" status but they sometimes reached "saint" or "minor deity" status :) The other problem I ran into with OO (a lot in the early 90's, less so as I got more experienced) was identifying what turned out to be an incorrect set of classes and then finding myself "stuck" when requirements changed and needing to completely redesign whole sections of the application. That's the aspect of static type systems that I don't like: if you make choices that seem reasonable but turn out not to match a future set of requirements, those types are _everywhere_ - woven into the very fabric of your application's structure as well as liberally sprinkled throughout any code that touches objects of those types. Scala helps with type inference but also expects you to encode even more of your application's structure and logic into the type system (which makes the "wrong type" decisions even worse when they pop up). Without a rigid type system, generic functions can operate on any compatible data structures without needing a typed wrapper (not even a parameterized type wrapper with inference). Yes, there's a trade off in that you can pass the "wrong" data but if you're test-driving your code (whether you do it in your head, in the REPL or with physical tests in code) and building it in small pieces, there's much less risk of doing so (IMO & IME). > with mutable states, i can "hide" that one additional parameter for the > one special case that would otherwise ruin my design by using a secret > static threadlocal or whatever else does the job. this is a pact with > the devil that will backfire when a certain threshold is reached, but it > *is* faster than doing a small refactoring every time. Faster overall, or just faster to the next marker post (and then a technical debt has accrued which must be repaid at some point)... > i'm pretty pragmatic here: sometimes doing it wrong now and doing a big > refactoring later is the better way. Doing it wrong and having a small refactoring later is OK but accruing a big refactoring isn't something I'd want in my code - but I guess it depends on what you define as "big" (and how "wrong" the shortcut feels). > can you give an example of truly generic code vs not so generic code? Not specifically. I'm not there yet but I feel I'm getting better... [PGP] > done Thanx Dennis! -- Sean A Corfield -- (904) 302-SEAN An Architect's View -- http://corfield.org/ World Singles, LLC. -- http://worldsingles.com/ "Perfection is the enemy of the good." -- Gustave Flaubert, French realist novelist (1821-1880) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
