mixins

[Stephen Cameron <st...@gmail.com>]

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? 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.

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.

[1] http://www.artima.com/articles/dci_vision.html

Re: mixins

[Stephen Cameron <st...@gmail.com>]

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 <da...@haywood-associates.co.uk>
wrote:

> On 6 December 2015 at 09:23, Stephen Cameron <st...@gmail.com>
> 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
> >
>

Re: mixins

[Dan Haywood <da...@haywood-associates.co.uk>]

On 6 December 2015 at 09:23, Stephen Cameron <st...@gmail.com>
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
>