5 ms·

I am wondering how people deal with complicated domain models, I have many objects that have a lot of properties (from 10 to 30), in Clojure I should represent

I am wondering how people deal with complicated domain models, I have many objects that have a lot of properties (from 10 to 30), in Clojure I should represent them somehow, probably with maps, the problem is I would have to memorize all the keys... How this is approached in Clojure in a proper "clojurian way", that is without doing something like using Java classes?

tsmarsh 7y ago
There isn't one way of doing this. Quickly figuring out if the model is good, I'd start with a map. If I'm feeling fancy I'll add a schema, if I need to I'll convert to a Record. Because of the way the language works you can probably make those changes without significant logic changes. Its a remarkable language.
dgb23 7y ago
It is difficult to grasp this from a distance. But generally: you can compose, destructure traverse/query and „update“ (in an fp sense) maps very freely and uniformly. So there is already an opportunity to model your data very differently and to deal with parts of maps in sane isolated ways by querying and destructuring. Structure in clojure is rather implicit. The benefit is that you can nail down structure where you need it typically with spec. A helpful hint could be that keywords can be namespaced. This can lead to better uniformity when structuring maps. Also your dev environment and approach matters here a lot, since you typically run a REPL while you develop, you evaluate forms incrementally and figure out details about your code ad-hoc, which goes way beyond just dealing with names. Hope that helps a bit.
slifin 7y ago
Most editors should autocomplete those keys for you if you want somewhere that is a centralised location to find those names you could consider using spec https://clojure.org/about/spec https://clojure.org/about/spec Spec 2 should separate two concepts, schema: all of the possible keys, and selection: the keys used in this particular function, Spec is also recursive Because spec is part of the language there is a growing ecosystem for defining specification once in spec then translating them to things like database schema, GraphQL schema, OpenAPI schema etc where they can be more "traditionally" understood You also get other cool things like you can generate conformant data examples given a spec, and use those to create generative tests, as time goes on I think our static analysis tools will start working partially with specs to further their abilities Specs also power things like this: https://borkdude.github.io/re-find.web/ https://borkdude.github.io/re-find.web/ and I think we're increasingly using them for validation, error detection etc in the core language too
- kls 7y ago
  Was going to highlight the same thing. even in OO if you are not using tooling like autocomplete, you have to mentally map all of those attributes. Fortunately autocomplete is fairly ubiquitous and it exists for Clojure as well. Visual Studio Code has pretty good support for Clojure via some contributed plugins.
  - int_19h 7y ago
    In OO, autocomplete can be driven by type information, which makes it that much more reliable and relevant.

tsmarsh 7y ago

There isn't one way of doing this. Quickly figuring out if the model is good, I'd start with a map. If I'm feeling fancy I'll add a schema, if I need to I'll convert to a Record. Because of the way the language works you can probably make those changes without significant logic changes. Its a remarkable language.

dgb23 7y ago

It is difficult to grasp this from a distance. But generally: you can compose, destructure traverse/query and „update“ (in an fp sense) maps very freely and uniformly. So there is already an opportunity to model your data very differently and to deal with parts of maps in sane isolated ways by querying and destructuring. Structure in clojure is rather implicit. The benefit is that you can nail down structure where you need it typically with spec. A helpful hint could be that keywords can be namespaced. This can lead to better uniformity when structuring maps. Also your dev environment and approach matters here a lot, since you typically run a REPL while you develop, you evaluate forms incrementally and figure out details about your code ad-hoc, which goes way beyond just dealing with names. Hope that helps a bit.

slifin 7y ago

Most editors should autocomplete those keys for you if you want somewhere that is a centralised location to find those names you could consider using spec https://clojure.org/about/spec https://clojure.org/about/spec Spec 2 should separate two concepts, schema: all of the possible keys, and selection: the keys used in this particular function, Spec is also recursive Because spec is part of the language there is a growing ecosystem for defining specification once in spec then translating them to things like database schema, GraphQL schema, OpenAPI schema etc where they can be more "traditionally" understood You also get other cool things like you can generate conformant data examples given a spec, and use those to create generative tests, as time goes on I think our static analysis tools will start working partially with specs to further their abilities Specs also power things like this: https://borkdude.github.io/re-find.web/ https://borkdude.github.io/re-find.web/ and I think we're increasingly using them for validation, error detection etc in the core language too

kls 7y ago
Was going to highlight the same thing. even in OO if you are not using tooling like autocomplete, you have to mentally map all of those attributes. Fortunately autocomplete is fairly ubiquitous and it exists for Clojure as well. Visual Studio Code has pretty good support for Clojure via some contributed plugins.
- int_19h 7y ago
  In OO, autocomplete can be driven by type information, which makes it that much more reliable and relevant.