Hi James,
Agreed, and I did feel a little dirty using a protocol simply to
satisfy the swap out for testing (when in fact redef isn't *that*
bad).
I had made a flawed assumption all along that accessing a protocol
method was different than a normal function (I though the 'cache' and
'queue' carri
The question you should be asking is: do I need polymorphism?
If the services you're passing in are distinct and not interchangeable,
then you can just use functions:
(defn my-service [cache queue payload]
(cache/store cache payload)
(queue/push queue payload))
On the other hand,
Thanks Shantanu. I am using component but not graph. Although based on
their schema library and om-tools I expect it to be pretty nifty :).
On 25 February 2015 at 14:32, Shantanu Kumar wrote:
> Having tried few other ways earlier, I now prefer the `first` approach you
> described. Protocols decou
Having tried few other ways earlier, I now prefer the `first` approach you
described. Protocols decouple the contract and the implementation very
well, and can be reified for various profiles (unit tests, scenario tests,
integration etc.) For constructing the graph I have found Prismatic graph
Hi,
I ran into a bit of a brick wall when thinking about how to register to and
dispatch to multiple micro-services and it made me realise the underlying
tension came from not having peace about a fundamental design decision; how
do you access your collaborators. Note: I am specifically talking
