Yes, I understand that. I know a lot about traits. I'm being hypercritical, because I hate sucky explanations.
I think too often people try to sound too smart.
Realistically, a more appropriate introductory article would be along the lines of what you just said.
As I said earlier, compiler syntax features are important b/c the average developer isn't a compiler writer, and it is tricky to get right. For instance, Sather had a way stronger notion of contracts than Eiffel, but never became popular.
Also, I think what Coplien/Reenskaug are *aspiring to* with "DCI" is what most good IoC containers such as Nicholas Blumhardt's Autofac do. Thus, I don't see it as a new concept. And, again, I see state machines and roles as complementary. In fact, containers like Autofac have a very Demeter Method Tools feel to them, too.
Most people, unfortunately, don't understand IoC and perceive it to be a technique for improving testability or whatever, when really it is best viewed as a data modeling paradigm.
@I think I wasn't clear. Let me try to clarify what I mean, because I wasn't trying to say that DCI promotes anemic domain models. Instead it challenges a basic assumption inherent in the notion of an anemic domain model. The assumption is that an object has a class.
My objects are aren't classes, either. In fact, my object models are very similar to constraint-based programming. The reason for this is to avoid the cross-product statespace problem you get with anemic domain models. This isn't DCI - it's just good modeling with math to back it up. It makes it much easier to comprehend performance, too.
Flat View: This topic has 119 replies
on 120 pages
[
«
|
333435363738394041
|
»
]