Jason, the summary is good, but I'm missing the more efficient data structure array-map that probably wastes less space than the hash-map for the same size of object. [1]
Also Zach Tellman has made some effort with clj-tuple which however use indexes, not keys. [2] [1] http://clojuredocs.org/clojure.core/array-map [2] https://github.com/ztellman/clj-tuple /Linus 2014-10-22 6:25 GMT+02:00 Jason Wolfe <ja...@w01fe.com>: > Hi Tom, > > Maybe this post from would be of use? > > > https://github.com/Prismatic/eng-practices/blob/master/clojure/20130926-data-representation.md > > It's my best attempt (albeit a year or so old) to answer many of these > questions. Happy to answer questions if you've got them. > > Cheers, > Jason > > On Thursday, October 16, 2014 2:19:32 PM UTC-7, Tom Oram wrote: >> >> Hello Clojure people, >> >> First up, apologies because this is going to be a long message. Howver, >> if you do have the time to read and respond, then I would be extremely >> grateful! >> >> Recently I've decided to give Clojure a proper go. Over the past year or >> so I've paid it a bit of attention: I've read books all about how to use it >> and I've spent a bit of time working through tutorials to create little web >> apps and so on. I understand the language (although not to any great depth >> yet), but I'm still unsure about the best approaches to actually working >> with it. >> >> I've got many years of OOP experience, and I'm a big fan of principles >> like SOLID and approaches like DDD. What I want to do now is, try and learn >> how to build well designed models using Clojure, while using best >> practices! I've started having a bit of a crack at it by building a simple >> app, but I'm finding myself trying to transfer a lot of my existing OOP >> techniques into Clojure. It's working, but I'm wandering if I'm overdoing >> it or perhaps just not doing things "the Clojure way". >> >> So, my very first question is are there any good books or resources on >> modelling, application architecture or best practices, using Clojure? >> >> Next up, maps vs records. I've read that the typical approach is to use >> maps until the design starts to solidify and then you can move to records. >> Is the the general attitude of Clojure developers or do some like to dive >> straight in with records? >> >> The next question is encapsulation: I've taken the approach that I'm kind >> of using namespaces like classes. If I want to create customer entity I >> create a namespace for it, then add a "make" function to it which returns a >> map of the right "shape". I'm then shying away from accessing the map >> directly, and rather doing it through other methods in the namespace which >> take the instance as a parameter. E.g. >> >> (ns app.domain.customer) >> >> >> (defn make [name, email] >> {:name name >> :email email}) >> >> >> (defn get-name [customer] >> (:name customer)) >> >> Is this a reasonable approach? If not, what might be a better one? >> >> This leads on to safety and defensive programming. Using the approach >> above, how much "type safety" is required? Obviously, in any API which is >> going to be used by other programmers, you've got to handle bad inputs >> well. But what is the Clojure approach in the "domain model"? Coming from >> the DDD mindset, where models are designed to be un-breakable, part of me >> wants to use records for all entities and typehint for them everywhere. >> However, I wander if the Clojure way is more about rigorous testing to make >> sure the wrong values don't get put in in the first place? Also, what about >> libraries like https://github.com/Prismatic/schema, this could be used >> in :pre conditions to be more explicit, is that a common thing? >> >> Next up, how far do you go with creating "types" vs using primitives? >> Again, referring back to DDD, both the email and the name in the example >> above are suitable candidates for value objects. In Clojure, would you >> consider hiding the data behind a set of specialised functions to create, >> access and use it? Or would you just pass the primitive >> string/map/vector/whatever about and work on it directly? Example: >> >> >> ; Given >> (defn make-customer [name email] >> {:name name, :email email}) >> >> ; Examples >> >> (def customer1 (make-customer "Tom" "em...@address.com")) >> >> ; vs... >> >> (defn make-name [name] name) >> >> (defn make-email [email] email) >> >> (def customer2 >> (make-customer (make-name "Tom") >> (make-email "em...@address.com"))) >> >> >> >> I think that's all I want to ask about now. I do have other questions >> about dependency inversions, but I'll leave that for another time. If >> you've read this far then thank you very very much! Also,I know that no one >> really wants to just sit and read though random peoples code, but, if you >> are interested in my (very very early stages) experimental project, then >> I've put in on https://github.com/tomphp/clojure-cocktails - any >> comments, critiques, PRs or questions would be really great! >> >> Thanks you so much for your times and I look forward to any thoughts or >> suggestions! >> Tom >> > -- > 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/d/optout. > -- 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/d/optout.
