Hi all,
I have a strategy that defines handling a woosey. Most woosey handlers are
going to need some help, maybe a wibbly and a woobly. In OO land I would
have a WooseyHandler { void handle(Woosey woosey); }. The implementations
would then receive Wibblies and Wooblies via dependency injection.
So far I have gotten away with passing in collaborators as parameters to
the functions, or if there are a lot of collaborators for ThingX I will
have a factory for ThingX which returns a map of collaborators that ThingX
needs and then pass that map as the first argument to ThingX's functions.
My question is now I have a genuine strategy - which seems to point to
multi-methods. Let's say that ThingX can now handle wooseys. Each
instance of ThingX is really just a map of its collaborators so that map
can't take part in the multimethod implementations. I could make ThingX a
record and then extend it but I am trying to avoid types as much as
possible...
So, how can I handle this situation? A strategy where the implementation
of that strategy requires more than the subject of that strategy?
Being well entrenched in Java I am consciously avoiding the 'kingdom of
nouns' and wrapping everything in a custom type, and so far it is working
wonderfully. Am I now too allergic to custom types?
Thanks!
Col
--
--
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
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
