Colin, I just read this definition from SICP, which made me think about your question again:
"In general, the underlying idea of data abstraction is to identify for each type of data object a basic set of operations in terms of which all manipulations of data objects of that type will be expressed, and then to use only those operations in manipulating the data." So that seems pretty compatible with your definition, except that as you said, in OO your operations typically have shared state in addition to shared data types. But I am not sure that I agree that having functions that operate on the data, rather than sharing state are more noisy. For example, these seem fairly equivalent to me: p/age(caleb) p/favorite-color(caleb) or caleb.getAge() caleb.getFavoriteColor() This assumes that you have defined 'age' and 'favorite-color' in a namespace that you have aliased as 'p' in the current context. That's an important point to me, because In addition to providing operations on shared state, objects and classes are also used to create namespaces for operations. In Clojure you can get namespaces a la carte (without having to use classes). I am fairly beginnerish at Clojure myself, but I have found its namespaces to provide some of the important conceptual glue that I relied on classes for in other languages. Otherwise you would have a lot of noise. SICP reference: http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#%_sec_2.1.2 On Jun 15, 1:41 pm, Colin Yates <colin.ya...@gmail.com> wrote: > Newbie so go gentle please :). > > I am an experienced OO Java developer (decade +) considering jumping fence > to a functional language, and clojure is pretty high up on the list for a > number of reasons. > > I am so used to defining everything as objects which are sealed units of > state and behaviour that I am struggling to see how to solve the same > problem with clojure. I desperately wish somebody would write a "domain > driven design with clojure" :). > > In brief, in OO state is exposed via a well defined API. That state may be > simple properties (values) or it may be calculations (functions). And > critically, the decision as to whether it is a value or a function is an > implementation concern. The Java Bean spec defines accessors for properties > of a class, behind which lies the logic of how to retrieve that state. So, > the very common Person class will expose get/setName(), get/setAge() etc. > and as a consumer I have no idea how the results are calcualted. > > In Clojure, if I understand correctly, the preferred way would be to use a > map (or defstruct) with keys such as :name and :age. These are then > retrieved as (person :name) and (person: age) etc. > > My question is if I suddenly decided that one of those values is best > implemented as a calculation, how can I seamlessly implement that. By > seamless I mean implement it without updating any consumers of a person? > For example, if I changed the age property to be the result of a function, > I could either replace the value of age with a function that calculates age > or write a function(person)->age. > > Both of those are disruptive to the consumers of person. > > I understand that clojure is about explicitly distinguishing between state > and functions, but I see this as a high price to pay. Have I missed > something? The OO in me is saying "well, never introspect a map directly, > rather provide get-X(person) functions" but that is very very noisy. > > That's enough for now - this is, I expect, the first of many cries for help > :) > > Thanks in advance to all who reply! -- 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
