Thanks for the illuminating response. You've given me a lot to look into here, and I really appreciate the feedback!
On Tuesday, April 10, 2012 5:37:20 PM UTC-4, Nick Vaidyanathan wrote: > > As I understand it, Protocols are intended to basically do what Interfaces > do in Java: define a contract whereby clients can reasonably expect certain > operations to be defined, irregardless of what they actually do. > > shameless opinion: this is a powerful and sexy sexy sexy language feature > that should be used by everyone. Program to an Interface, not an > Implementation<http://www.artima.com/lejava/articles/designprinciples.html> > . > > You are basically replicating the Interface-->Abstract Class--> Concrete > Implementation pattern in Clojure. > > Some might immediately regard this as an OOP-type "code-smell", in the > Functional world. But I would argue that the very introduction of Protocols > in Clojure suggests that there's value in this pattern. > > There are times when your clients want to be assured that certain > functionality is available. > > There are also times when a framework designer wants to be able to say > "make whatever piece you want, but in order to maintain semantic cohesion > with the rest of the pieces you must provide this functionality." > > There's a reason this Language Pattern comes up again and again. > > What you're doing, in this sense, is enabling easy understanding of your > system by adhering to Domain Driven > Design<http://domaindrivendesign.org/resources/what_is_ddd>, > keeping things Simple (concepts have first class representations) and Easy > to understand (the concepts themselves are small). > > Your clients only need to know about your Protocols and your Entity. They > don't ask an entity about its state and then do stuff. They tell an entity > what to do based upon the operations it declares it can do. You define > dummy operations, then each individual entity says "I'm not dumb! I > actually do stuff!" only about the things it cares about/can actually do. > > Seems reasonable. > > You can contrast your usage with others such as Luke VanderHart's Domina: > https://github.com/levand/domina/blob/master/src/cljs/domina.cljs, which > seems like a fantastic use of Protocols to abstract away details of > handling nodes. > > Though, personally, I find putting all of that in one file to be one giant > code smell. There's a Parser hidden in there. The concept of a Node is just > screaming to get out into its own space. A Debug mode is just praying to > get away from all this other noise. A StyledNode is wondering why no one's > ever considered that it's a really pretty Decorator that makes Node easier > to understand in isolation but much nicer in application. > > I like your approach better. I would like it even more if you're being > extra considerate and keeping things to Miller's Magic > Number<http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two>for > information processing (and code comprehensibility) by having separate > files with a nice package structure, such as: > > domain/Entity.clj > protocols/Movement.clj > domain/AbstractEntity.clj > domain/Farmer.clj > > My only feedback is to think about the size of your Movement protocol. Are > asset and data really cohesive to the idea of movement? I'm unclear as to > what you might mean by such names, so it's hard to tell. Is inspecting and > materializing really a part of Movement? Are asking questions about > destination really key to the idea of Movement? Is location really a > function of Movement, or a first class piece achieved via movement? > > Ideally Protocols should be small. Perhaps you have another Protocol that > extends Movement? Perhaps you have a Watcher Protocol that asks questions > about destination? An Organism, that extends both Movement and Watcher and > tries to survive? > > Keeping such pieces small and composable, highly cohesive and loosely > coupled, increases your flexibility in the future. > > My Not So Humble Opinion: Not only is it correct, it's also beautiful. > Keep using it this way. > > On Tue, Apr 10, 2012 at 7:44 AM, tmountain <tinymount...@gmail.com> wrote: > >> I'm working on a behavior simulation demo in Clojure, and I've opted to >> use protocols as a mechanism for composing entity capabilities. This >> snippit of code demonstrates what I'm doing: >> >> https://gist.github.com/2351790 >> >> Everything is working so far, but I'm wondering if this is an idiomatic >> usage of protocols and records. I ask this specifically because I'm getting >> a code smell type feeling in duplicating all the keys from Movement in my >> base-behavior map. >> >> -- >> 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 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
