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 >
