I agree with Gary, there's normally not really any need to obfuscate the
implementation,
and using the underlying structure can sometimes be useful.
That said, if you really want to, you can create a "woobly" protocol and
implement it using reify, this will make the underlying implementation
completely hidden.
(defprotocol Woobly
(add-job [woobly job]))
(defn create-woobly
([] (create-woobly 100)
([queue-size]
(let [queue (java.util.concurrent.LinkedBlockingQueue. queue-size)]
(reify Woobly
(add-job [woobly job]
...use queue...)))))
Jonathan
On Thu, May 9, 2013 at 6:15 PM, Gary Trakhman <gary.trakh...@gmail.com>wrote:
> If the interface provides everything that's needed, then there will be no
> need to dive in?
>
> I find attempts to hide that stuff frustrating when I'm a consumer of the
> code, if I need it, and I acknowledge that implementation details are
> subject-to-change when I take that risk, so only having something clearly
> marked off by documentation of intent would be what I would do as a
> producer of the code.
>
>
> On Thu, May 9, 2013 at 12:07 PM, Colin Yates <colin.ya...@gmail.com>wrote:
>
>> (newbie, but trying hard!)
>>
>> I am designing a Woobly. A Woobly is non-trivial and has a number of
>> internal data structures (queues, worker threads etc.). You can 'add' and
>> 'remove' jobs from a Woobly.
>>
>> In OO land I might have a Woobly interface with the various methods which
>> provides a public API. I might also have a factory or more likely builder
>> somewhere which creates Wooblies.
>>
>> The part I am struggling with is how to create a Woobly without exposing
>> its internals. Let's imagine that Woobly uses an internal
>> LinkedBlockingQueue of a certain size.
>>
>> Option 1 - a big bag of data.
>> I could create a map of config/state/data that comprises the
>> implementation and have the creator function return that. Consumers can
>> then call other methods passing back that bag of config/state, but what
>> stops them simply diving into that bag themselves? For example:
>>
>> [code]
>> (defn create-woobly
>> ([] (create-woobly 100)
>> ([queue-size] {:queue (java.util.concurrent.LinkedBlockingQueue
>> queue-size)}))
>>
>> (defn add-job [woobly job] ....)
>>
>> ;; nothing stopping me diving into that state...
>> (.clear (:queue (create-wobbly)))
>> [/code]
>>
>> Option 2 - protocol and deftype
>> Alternatively I could implement an IWoobly protocol and create a single
>> deftype which is instantiated and returned from the 'create-woobly'
>> function? I am not sure I like this as it is really back to OO isn't it?
>>
>> I want to retain the notion of create returning a handle which is the
>> first argument in the other public functions, but the first way just feels
>> far too dangerous.
>>
>> Am I overthinking this - what do you all do to address this?
>>
>> Thanks a bunch.
>>
>> 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.
>>
>>
>>
>
> --
> --
> 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.
>
>
>
--
--
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.
