In practice, these days I occasionally find myself writing code that uses dynamic dependency injection as a means to keep responsibilities separated and make classes simpler. So it’s a tool I’m using at least.

Greetings Petter! Did you ever get validation for this idea? I too have a problem with “injecting algorithms into objects” and I agree it should be reverse. I like your football analogy BTW.

I wish that some day Trygve would publish his horror stories of the problems that self schizophrenia caused in the nascent implementations leading up to DCI. It’s a real problem.

I also had a client in Austria who was using your approach, and we uncovered a fatal flaw in their architecture during an architecture review I did there. It had been causing them problems for years in a large, complex system, and they never had been able to find it.

The Traits puzzle piece is, to me, the shining diamond of DCI. Most people intuit that it is impossible to do anything like it and so they dismiss it out of hand. Just look at the old discussions on object-composition surround ObjectTeams. One of the documents I read (I don’t remember if it was ObjectTeams or Elmo) said that self schizophrenia is “not often” a problem. I want my software to work correctly *all* the time, not just often. But this good-enough mentality seems to be sweeping the software world — probably because of the web, whose intrinsic diminished reliability masks the underlying sloppiness.

This stuff is hard. Trygve has been working on it in some form for about a decade and I have been working together with him for three or four years, and with other people like Sebastian more recently. We’ve been over these kinds of issues again and again and again with long deliberation and hundreds or thousands of eyes poring over it. We’re of course always looking for newly uncovered pitfalls and of ways to do them better. Let me encourage the readers out there to contact us if you discover DCI improvements or pitfalls — before publishing it in a ‘blog after reading two or three papers and spending a few days putting together code using known techniques that do not arise to the occasion.

> I had looked at Qi4j a year or so ago and again just
> before writing this post. Both times I felt the same:
> while I can appreciate where they are trying to go and
> would probably like to use a framework like that,
> the syntax that they have achieved makes me feel
> Java isn’t a great choice as a language to implement that
> type of framework.

To loosely quote the rationale given by a noteworthy ‘blogger of our times: I hear that it’s unlikely, for a large number of reasons, that they will be abandoning Java in the near future. :-)

Self schizophrenia seems to be what you would get with my proposed solution for dealing with the layering problem introduced by static class composition, though. The top-layer proxy objects that would delegate some of their work to domain objects seem to exhibit exactly that, although I am not sure if that is a problem in practice.

I had looked at Qi4j a year or so ago and again just before writing this post. Both times I felt the same: while I can appreciate where they are trying to go and would probably like to use a framework like that, the syntax that they have achieved makes me feel Java isn’t a great choice as a language to implement that type of framework. (Maybe because it’s not “real”.) But it’s definitely a technology I am watching.

I will continue reading about this, it is certainly interesting and I’m learning lots of stuff. And, who knows, maybe one day I will make an intellectual breakthrough! ;)

I don’t think that was your point. Your point was that what DCI does can be done by DI, which I don’t think is true. There is no need for a discovery or claim of DCI not needing class composition; the majority of published examples, to my knowledge, already lack class composition.

Much of the semantics of DI is already present in our implementations of DCI, so I do not understand at all what you mean by combining them. Dependency injection is about relaxing static dependencies, and it solves the problem at the expense of object identity. Most implementations based on dependency injection (e.g., Elmo or ObjectTeams) end having the problem of self-schizophrenia. If you look at the Wikipedia definition of DCI, it requires that the solution retain object identity. One reason for this is that issue of object programming that you are struggling with. But the other is much simpler: the identity of the injected object and the injectee are not in general interchangable, and this leads to a homogeneous mixture of these two identities in a single program. In general, such a program will simply not work.

Solving this problem was the last bit of the puzzle in getting DCI to work. It’s why we use traits in general, which tends to look like class composition in the world of classful languages, and which tends to use more dynamic MOPs in real programming languages. As you pointed out, Java has neither, so Java needs to be augmented to make it into a higher-order language like Qi4j.

Maybe you should have a look at Qi4j: it may be what you need to make the intellectual breakthrough that still seems elusive.

@James and Sebastian: I intended to write ‘some of the main people’, not ‘the main’, I have updated the comment. And Sebastian, your blog is mentioned prominently in the DCI documentation, so you’ll forgive me for making that mistake. :)

@James re point 1 above: I should be clearer about the reason why I don’t think that static class composition as described in the DCI examples scales to large systems: the things that need to change quickly are of course use cases/contexts, then roles, and somewhere at the bottom are the domain objects. This translates into layers, where a layer below knows nothing about the layer above. If the core domain objects need to know about every role they can play in the system, as the examples of static class composition indicate, then the layering collapses and you lose the advantage of having differentiated rates of change. You can launch a production system without that differentiation, but code reuse and system evolution will be painful.

I’ve realised that there is (at least) one way to get working layering with static class composition, though: instead of having the actual domain model class instantiated as the objects that play various roles, there could be proxy classes defined in one of the top layers of the system. These proxies would delegate the domain logic to an instance of the actual domain object, and would essentially correspond to “a list of the roles the domain object can play in this part of the system”. It’s a bit of extra plumbing, but it could work.

@James re point 2 above: That’s exactly my second point – it seems to me that a large part of DCI doesn’t require class composition. The spell checker example in the post gives me reason to think that DCI+DI is a very promising avenue to explore with regard to some problems that I am seeing in my day job and that you’re referring to in your talks: algorithm “explosion”, getting layering right, and simplifying the objects involved in the algorithms by removing conditional/extraneous logic through doing more precise wiring up in the contexts (I don’t believe you mentioned that last point, but it is relevant to quite a few scenarios I encounter frequently).

It is very unlikely for a large number of reasons that I will be abandoning Java in the near future. But it is very likely that the next system design I work on will be heavily influenced by the thoughts in DCI.

The main person in DCI miss being mentioned in your article, and you seem to have missed most of his publications on DCI — which are perhaps the most comprehensive, direct, and authoritative sources on the topic. That would be Trygve Reenskaug. While the mano-à-mano discussions here are fun, I’d really commend the written sources to you. I can even plug the new book Lean Architecture, which includes two chapters that introduce DCI and has four or five appendices with examples in different programming languages.

> Still, I don’t think that affects the point about static class composition:
> I don’t think that it scales to larger systems.

1. I would believe that you might be right except we have many working examples of this working in the industry.
2. This has very little to do with DCI per se, as the above comments corroborate.

Best,
Cope