On Oct 31, 2011, at 2:03 PM, Timothy Baldridge wrote: > This is what Clojure excels at...de-coupling, or as Rich put it in his > recent talk "Simple made Easy": don't assume things about your code. > Don't assume that all models will always fit into the concept of a > polygon...don't assume that you'll always want to represent your > models via Java2D.
It's impossible to make zero assumptions about your code; the trick is figuring out which are the appropriate ones. Making too many assumptions leads to brittle and hard-to-extend code, but making too few leads to over-generalized, ponderous code that does way more than it's ever likely to be used for. In a case like this game, it should be easy to refactor away from the "everything is a polygon" model if and when the game outgrows it, so I'd argue against introducing the extra complexity of per-entity renderers until it's actually necessary. That's a strength of dynamic, expressive languages like Clojure, IMO: because there's so much less code, refactoring is much easier. So instead of trying to predict all future requirements and possibly ending up with over-generalized code, you can make assumptions based on current/near-term requirements and refactor when those assumptions no longer apply. -- 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
