-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 i went a step further:
since my asteroids are all immutable, they don't contain a renderer. the renderer would either require a reference to the asteroids data, position, size and so on - if that "changes" the renderer would be obsolete - or would require its caller to know about the internals of asteroid rendering to the caller can then pass the polygon, position and so on. both problems are solved by a rendering-factory :) any game element carries along a renderer-factory that just requires a a game element as a parameter. that way i can just do: (render ((:gen-renderer game-element) game-element) target-image) for all game elements. if a game element get's replaced by a new version of itself, the renderer factory can just be carried along, no need to do messy internal updates. decoupling rocks. Am 31.10.2011 20:54, schrieb Michael Gardner: > 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. > - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOsEKNAAoJENRtux+h35aGe7kP/37maMjp1c+x7yBd77HA52Xo ap7LO0EL43jcwie28y7iK3qkRT2O12wxCpHMD9RmyCIO3g68H1CmOIrVhT9JYs5g Q/fjsilXg9kmgHvimATTDsTRng7wg4mNIh3l9n4ZpOj11Q+Ib7aK9DEynUsr2474 PTKsIxiIscD2ZDkb4Xl0qoZBnLj9m2o3xzXTMPkNUEXEepC4MVzuFWowxWsemJ6k zk9MuaxY7NzKYzdmtAm0UBg2RrtaFfWDSfLobpIp7g3i9es+9WpfCToCj9GdcIdS bwCaU76AUiS2SJf9Ti8Q5DCtFw2dkICnLqBSYbp4xkO+0aU5ihdEXNF+PpEul087 ic/pxsg0jBzwwy05hngxGx9vlx1zFUjN5A3WLWFLlsWhfkBGPo90LTj+7P+t3mch y2QLoqLZHOlRA2+r8emFJJhRXQeqHHecTEBy8q0vPPhC9QH1ejt7d4jF2yRi/rkk UZHJxUqH8yxMzqIj27BGojJUz6UVr7JH/VwWQpuYNLn3I7ThV6J2l8xKcD00SUcX HjLP4TpM2CT/eJTlUEzm8wzqrSQdN+2XmT5u5x4YNasz2FC61C9bd03Po8WvX2gW bG+X2GjIaqslzRgP4/NUMkL9FVXD5OY1kkaD6ZXmysTQRNAttTu9VUHahchfsxvk CPVHu/tMkv4A4EfQFxos =JsnE -----END PGP SIGNATURE----- -- 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
