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.
