|
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, > academic > > > 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). > The > > > Qi4J environment (Richard Öberg and Steen Lehmann) is > > > pushing forward the ability to express traits in a > Java > > > environment. > > > > > > Why aren't you linking me directly to implementations > so > > I > > > can play around with examples? One of Kay's big > tenets > > is > > > learning should be constructive. Instead of letting > me > > > 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, > but > > may not have been released publically. I'll post here if > I > > find a link. > > > > Anyway, this is an idea article. We'll be publishing > more > > articles exploring this area that will be more hands > on. > > 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 > a > > 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 > application. > 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 > example: > > 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 http://www.joelonsoftware.com/items/2009/03/09.html 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.
|
|