Does DCI look procedural to you?

I just wrote this on comp.object, but I don't think the group is active anymore, so I post it here, as this seems like an active forum.

I started reading about Data-Context-Interaction (DCI) recently. I still don't get everything yet, but one thing I noticed is the code looks overly procedural to me. DCI seems to keep the methods over here, and the data (dumb objects with basically only getters and setters) over there.

Still, I think there might be some nuggets of truth in DCI, and I thought I would ask people on Google's object-composition group why it seems procedural to me, and what could I be missing:

https://groups.google.com/forum/#!topic/object-composition/X1oZUnQXVTI

Um, ouch! Bad Idea. OK, it's all good.

I am hoping this group has more diversity when it comes to different ways of coding, and can see the pros/cons of various approaches. So ...

Is there anyone here who has heard of DCI? If so, what experiences have you had with it?
closed account (z05DSL3A)
You had a run in with Cope? I remember when he came here, it didn't go so well.
I've been reading up on this concept since you made this post and I don't think you're missing anything. This guy doesn't seem capable of communicating his ideas in any meaningful way and that does more damage to the credibility of his claims then he seems capable of understanding. Honestly as I am reading the thread that Canis Lupus referred to ( http://www.cplusplus.com/forum/lounge/54899/ ) I am having a very difficult time picturing this guy as anything but some scarf wearing hipster who just wants to talk at people because it makes him feel important. The Wikipedia article ( http://en.wikipedia.org/wiki/Data,_Context_and_Interaction#Implementing_DCI ) on this isn't any better at explaining this "concept" so I am left with the impression that this idea is nothing more then his attempt to gain attention by needlessly complicating things.

All he is doing is describing classes in a very odd way and then telling you that the way you are using classes is wrong. Instead you should write far more code then you would normally write because that will help people who can't understand what your code is trying to do to understand your code. Despite the fact that nobody understands what he is trying to describe, his model for describing things is better. Instead of doing this:
1
2
3
4
5
6
7
8
9
class OBJECT
{
    private:
    int Number_Data;
    char Character_Data;
    
    public:
    Role();
};

I guess he is saying that you should do something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
class DATA_1
{
      int Number_Data;
      char Character_Data;

     friend DATA_1 Role(DATA_1);
};

class DATA_2
{
      int Number_Data;
      char Character_Data;

      friend DATA_2 Role(DATA_2);
};



class INTERACTION
{
     private:
     DATA_1;
     DATA_2;

     public:
     DATA_1 Role(DATA_1);
     DATA_2 Role(DATA_2);
};


Why? Because evidently objects, in the form of classes, have nothing to do with object-oriented-programming. He actually makes that statement a number of times.
Last edited on
closed account (z05DSL3A)
Computergeek01 wrote:
This guy doesn't seem capable of communicating his ideas in any meaningful way
I have his book, Lean Architecture: for Agile Software Development, I haven't managed to finish it yet.

From what I understand DCI is an architecture paradigm.
@ Canis Lupus: Does he ever explain what the "End-user mind model" is?
Sadly @Canis Lupus, you didn't tell me about the thread here before I posted there :-)

I didn't think such a smart and educated man would talk to anyone in that fashion, especially someone stupid like myself. He is suppose to be a certified SCRUM master, and believes in communication over documentation like everyone else in the agile community. I guess SCRUM didn't teach him everything.

@Computergeek01, thanks for responding. I appreciate your help, and you make a good point.

The problem from what I see is compile-time versus run-time. They like to speak about DCI from the run-time perspective. Unfortunately, I don't write code at run-time, I write it at compile-time.

When looking at the code at compile time, I mentioned it looks procedural to me. The code is split into methods on one side, and dumb-objects (basically structs) on the other. This makes the code look overly procedural, and is subject to many of the same problems procedural programs have.

Also, the main point of DCI was to align the code with USE-CASES. In use-cases you will often see people speak more about roles than plain objects, but here is another problem I see with DCI. Why can't we use what already exists -- interfaces?

In this approach, we keep the objects smart, and use roles to show only the methods in the larger object we need during a use-case scenario?

I think what interests me the most now is how the group treats Cope like a zen-master. One person told me that calling me a novice and stupid was his unique way of teaching.

Now, this doesn't mean DCI is wrong, just that I don't fully get it yet. Also, Coplien is an incredibly smart and talented individual, so I assume what he is saying does have some merit.

I also must mention that after being attacked a few time I finally said he was acting like a fool, which was clearly wrong on my part. I just wish we could talk more openly about methodologies without everyone blowing up.
Last edited on
I guess learning more about DCI will have to wait. Cope banned me (I think he saw this thread) and everyone else thinks DCI is crazy. LOL!

Maybe I will make up my own Architectural paradigm.
Topic archived. No new replies allowed.