Thanks Dan, I want to keep thinking on this but best to play with a few things first and come back later on with more questions.
But one quick question: Is it possible to implement my own Note class and plug it in to the notes module in the same fashion as adding 'Notable' does? On Mon, Dec 7, 2015 at 12:38 AM, Dan Haywood <[email protected]> wrote: > On 6 December 2015 at 09:23, Stephen Cameron <[email protected]> > wrote: > > > Hi, > > > > I've been reading up on a few things today, and came across the reference > > to the DCI architecture in the mixins section. This discussion of the > > separation of data-model from behavioural aspects (roles/algorithms) is > > what I have been thinking of for a while, in fact I now recall reading > that > > paper [1] some time ago, and maybe those ideas seeped into my > subconscious > > then. > > > > Is there an example, maybe in Estatio, where that approach has been used > > and provides a good example to study? > > > > Not in Estatio, but I've used it in Apache Isis itself for the Dto marker > interface [2] use case (so can download XML and XSD for a JAXB-annotated > class that implements this interface), and also in the incode note module > so that can add/remove notes to any entity that implements Notable [3] > > > > > > I'm specifically interested in the > > idea of data objects being given behavour vai mixins that then allows > them > > to be participants in a complex process, one that is maybe 'orchestrated' > > by the same object that contributed the behaviours. I think this is what > > Reenskaug and Coplien are talking of as a 'context', specifically account > > objects being given roles in a bank transfer transaction process. > > > > > In Apache Isis' implementation the binding of roles to an object is static, > based upon its type (class hierarchy / implemented interfaces). I could > imagine in the future this might become dynamic, though exactly how one > expresses the "context" I am not sure. > > > > I am studying some legacy code for work and finding it difficult to > > understand, the behavioural aspect is obscure. It will provide some > > interest to at least prototype something better using Isis, to continue > my > > learning curve. > > > > > Because Isis uses the static type to bind the mixin to the domain object > implementing the type (interface), it means that the information needed of > the mixin upon the "mixee" is well-defined. In the case of Notable_addNote > and Notable_removeNote mixins, because they use the isis-module-poly class, > this actually means that Notable is just a marker interface. But one could > imagine a different implementation where Notable might require that > getNotes() is exposed as a collection, and then the mixins interact with > that (and only that) method. > > More generally, I see mixins as being a useful way of keeping to the single > responsibility principle and in particular the interface segregation > pattern; they are also useful trick for inverting dependencies. In other > words, the S, I and D of SOLID [4] > > HTH > Dan > > [2] http://isis.apache.org/guides/rgcms.html#_rgcms_classes_mixins_Dto > [3] > > https://github.com/incodehq/incode-module-note/blob/master/dom/src/main/java/org/incode/module/note/dom/impl/note/Notable_addNote.java > [4] https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) > > > > > [1] http://www.artima.com/articles/dci_vision.html > > >
