Throughout past discussions and explorations of ideas – during sprints and online calls – about upcoming innovations of Neos, I have encountered together with some of you, in several instances of really hard to solve problems, conceptual challenges and open questions
… e.g. a complexity challenge in implementing privileges / policies and the definition of
- layers (framework, application, user) and
- contexts (e.g. ui area, content type, node),
within which the privileges
- can be defined
- reasoned about and
- determined (calculated)
… another example is the possible reimplementation of Nodes / a NodeInterface, in order to make them extensible and the accompanying discussion about Composition-over-Inheritance, protocol of interaction with Nodes etc. — talked about in the recent weekly ESCR call.
… and of course there is more examples, including of code, that wants to be refactored.
Looking at the Flow Framework and Fusion, I am able to see certain concepts (e.g. AOP, Fusion context, Dependency Injection, Late Binding etc.), that are useful in reducing such complexity by dividing up the problem space along suitable axes, already being used in Neos.
I was impressed to learn from @robert, that the very conception of Neos was founded in the desire to make use – among others – of SOLID patterns. Along the lines of this inspiring idealism, and because I am confident it will contribute value to everyone’s programming of / with Flow and Neos – not only in helping solve above mentioned challenges – but in general and at the core …
an architecture for networks of interacting objects, an intuitive way of thinking about problems, that involve data objects and their interactions within a context — a programming approach, that immensely increases the ability to write understandable code in the form of explicit use cases and increases the programmer’s confidence in correctness of their work, in almost any programming language.
It was invented by Trygve Reenskaug – the same mind, that gave us the MVC pattern.
Data, Context and Interaction give it its name: DCI
For you to see, what it’s all about, I’m including a following example – which is by no means a perfect implementation of DCI – for you to study, as well as a couple of in depth going talks by James Coplien (@jcoplien) and articles.
In essence – in my own words – a context object (e.g. a Money Transfer):
- contains (Composition)
- all data objects, that are to perform an interaction (e.g. two Accounts) as Roleplayers, which play a Role
- the “script” for the interactions between the abstract Roles
- and their contextual environment
- initializes everything necessary for the interaction to occur upon its construction (late binding)
- provides to the outside only methods relevant to the interaction and context (e.g. a MoneyTransfer)
— It’s basically an already aimed and loaded gun (the MoneyTransfer), that only needs to be triggered (call of Transfer method) – with the option of providing an amount of how many bullets to fire (Amount) – everything else is encapsulated away and taken care of within that gun.
— or like a role-play with a stage on which concrete role-players are assigned certain predefined roles and given a pre-written script, that they only have to carry out
A context itself (e.g. a Money Transfer) can also be an object within another larger context (e.g. a Payment for a Product).
- if you were already familiar with DCI or some of the concept
- where in Neos & Flow you see potential for the use of DCI
- how DCI may contribute to your own programming
- which concrete problems you’re able to approach differently
(easier, more elegant, better understandable), using DCI
I would appreciate your feedback.
So, here you go:
one example (see the repo for a full picture):
These are talks, that explain DCI and its use in more depth: