Re: The DCI Architecture: A New Vision of Object-Oriented Programming
Posted: Mar 27, 2009 10:42 AM
> > > You are way more infatuated with the abstract,
> > > angle of this topic than concrete examples of how to
> > build
> > > working systems. To prove my point, your references
> > are
> > > all academic stuff, such as Alan Kay's and Doug
> > > Englebart's visions of computing. There is nothing
> > wrong
> > > with linking to these things, but I am dumbfounded as
> > to
> > > why you aren't directly linking to the following:
> > >
> > > @DCI implementations also exist in C#/.Net (Christian
> > > Horsdal Gammelgaard), Ruby (Steen Lenmann), Python
> > (David
> > > Byers and Serge Beaumont), and Groovy (Lars Vonk).
> > > Qi4J environment (Richard Öberg and Steen Lehmann) is
> > > pushing forward the ability to express traits in a
> > > environment.
> > >
> > > Why aren't you linking me directly to implementations
> > I
> > > can play around with examples? One of Kay's big
> > is
> > > learning should be constructive. Instead of letting
> > > play, you're linking me to more theory that I have to
> > > digest before I can go play.
> > >
> > > No, no, no. Just no. Let me play with the code.
> > >
> > I'm not sure there's anyplace where that code has been
> > made public. I'll ask. It is not secret or anything,
> > may not have been released publically. I'll post here if
> > find a link.
> > Anyway, this is an idea article. We'll be publishing
> > articles exploring this area that will be more hands
> > We'll do something on Qi4J, but I would point out that
> > Qi4J isn't DCI. What they have in common is that DCI has
> > concept of roles that is implemented with this concept
> > traits, and Qi4J provides a way to do that trait-like
> > concept in Java.
> As for the C# implementation mentioned I have only made a
> small proof-of-concept example, but I am working on a
> larger example, which will give a better impression of how
> nicely (or not) my implementation would work in a real
> The C# approach is to use C# interfaces for methodless
> roles, use C# interfaces and extension methods for
> methodful roles, and just use POCOs for context and domain
> object. To be concrete the following is a really short
> namespace AccountSample
[i]....excessive code, with casting![/i]
I agree with an earlier poster, about DCI, IoC, AOP, and event based programming, all are seriously flawed:
* they obfuscate code
* they make it even harder to design, understand, test, and especially debug side-effects!
* they can lead to ironically unexpected, and nasty, binding side-effects, including hard to trace data security and thread-safety issues.
* indirect binding can seriouly slow down execution, because too much indirection can sabotage VM runtime optimisations.
* they are another place for the code to break, due to subtle bugs.
* any API which injects code, relies on a less secure code definition, or uses reflection to access object internals, maybe a security risk, or introduce hard to debug runtime bugs.
I looked at Qi4j, and found numerous stupid mistakes on the web site, including in the code examples, this didn't bode well for design and code quality, but I was still shocked at just how full of over-abstracted IoC, and verbose framework boilerplate code, the examples were! The examples even included reflection code, when a Facade class would have been simpler, and been ripe for VM runtime optimisations.
IMHO, a transactional money transfer would be better managed by separate immutable reversable command, multi-object lock, and transaction objects; these could be inherently thread-safe, easy to track, easy to test, trivial to audit, and be made to enforce business rules, without any need for arcane frameworks, IoC, AOP, dodgy injection wild-cards, or other unsafe dynamic programming recklessness.
Have a read the Specs? Really? That’s so unagile section of
I suspect that the main reason for this back-breaking dynamic language nonsense, is that some Agile programmers have to do over-kill code abstraction, because of inadequate or out-of-date specifications; I've been there, it was not fun, it made quoting a gamble, due to creeping featurism, so caused significant delays for software delivery.
The developing financial recession/depression process has forced Development, at my employer, to realise that this specification inadequacy was untenable, so we now insist on bounded, signed-off specifications, for bespoke customer work; this allows realistic quoting, and rebuffs cheeky customer bugs, for the new, and often expensive, functionality.