Hi everyone,
I have been studying a lot about the responsibility-driven design and have read almost all the posts on this forum as well.
I read Craig Larman's book Applying UML and Patterns. This book explained the general principles to assign responsibilities to classes.
The process explained in the book first creates a domain modal which objects having attributes and associations. Then during design phase responsibilities are assigned.
The main principle is Information Expert which states that responsibility should be given to class that has the information to fulfill it.
My question to everyone here and especially Rocky is that whether he agrees with this concept? To my thinking this is a data-centric thinking because we are allocating attributes to the classes first and then based on that we are distributing behavior/responsibilities.
I would really appreciate feedback from everyone.
Tahir
I think that principle is backward.
An object gets responsibility because you have a responsibility that needs filling, so you define an object to do that work.
THEN you decide what information each object requires to perform its responsibilty.
If you assign responsiblities based on information, you'll end up with objects that have multiple responsibilities, and that violates the single-responsibility principle.
Hi Rocky,
Thanks for the reply.
Sometimes I feel that RDD or BDD is procedural way of doing things. We are allocating procedures to different modules. I am for sure missing something!
Last couple of projects on which I have worked, I created classes by taking inspiration from real world, as suggested by tons of books out there. I allocated attributes and THEN behavior based on those. The result was that my classes were difficult to maintain because they started doing a lot. Sometimes classes didn't do anything and there were few controller type classes that had all the behavior.
Is that what you call data-driven approach? I can see now that how I can improve the design by seperating behavior rather than data. The trouble is that RDD is also being abused, everyone say that their approach is RDD. GRASP Princples are also RDD, according to the book. It is difficult to understand the true nature of what RDD means. What exactly is a responsibility? Is it GetCustomer() method or is it more abstract like 'Add/Edit valid Customer'. May be you can help me clarify these concepts.
As a simple example, if I have a Customer object whose responsibility is to 'Add/Edit valid Customer' and it looks like CSLA.NET object. Now if I need to make a copy of this object then Information Expert principle would suggest to put it in Customer, something like
Dim NewCustomer As Customer = OldCustomer.Copy()
OR
Do we create another class, something like CustomerCopier and that takes a Customer and gives us a copy of it? e.g.
Dim NewCustomer As Customer = CustomerCopier.MakeCopy(OldCustomer)
Is this Copy a responsibility or a behavior? Where would you put it? It is a new/seperate behavior so should it be in Customer or in CustomerCopier (i.e. outside Customer)?
I would really appreciate and be very thankful if you can provide me with some thoughts about this.
Tahir
Words become overloaded. This is the nature of language, for better or worse (I find linguistics to be facinating by the way).
So "responsibility" can, and does, mean different things to different people. For a very long time I resisted using any common labels (like RDD) for what I am talking about. Because as soon as I use one of those labels, I get all the baggage that comes along with them.
Just like talking about Agile, or TDD, or the use of patterns. All those labels have accumulated a lot of baggage as they have moved from niche concepts into the mainstream. By the time they get into the mainstream, the labels are virtually meaningless, because they've accumulated so many meanings and so much baggage. Agile can mean almost anything you want it to mean as long as you don't create many (any?) documents. TDD is not about quality, even though "test" is in the label. Patterns are good, and if you use them (even inappropriately) you can be proud. The more the better, even if the results are bad.
So I still try to avoid using labels for what I do. I do what works for me. And I try to describe what I do without resorting to labels.
Are you a Republican? Democrat? Labor? Socialist? Progressive? Green? And if you pick any one of those, you automatically fall into a niche definition that you disagree with.
So you can read all you want about RDD. And then it is up to you to take from that what works for you and leave what doesn't work for you.
Someone (you?) said that sometimes responsibility-driven design (like I talk about it) seems more like procedural design. That's somewhat true. It is actually closer to modular design if you get right down to it. Procedures have no concept of encapsulation, while both modules and objects do have that concept. Therein lies the key difference between responsibility-driven OO design and procedural design.
In procedural design each procedure has a responsibility. That is true. But procedures have almost no encapsulation. They can't maintain state over time. So their responsibiities must become very narrow. Narrow enough that they can fulfil the entire responsibilty within the context of a single procedure call.
The same is true of services in SOA and of activities/tasks in workflow by the way.
In OO design, each object has a responsibility. But objects can (and often do) encapsulate state. They can maintain this state over time. So their responsibilities can be broader, and can encompass a set of related behaviors that fulfil this broader responsibility.
In the end, procedural design must equate responsiblity with behavior: responsibility=behavior=procedure.
But objects can encapsulate higher order concepts. Higher order responsibilities. A number of behaviors required to implement the responsibility can be included in the object, along with the state necessary to make it all work.
The real trick with objects is to allow the responsibility to become too broad. And the way you know this is that your object starts to have conditional logic so it works one way sometimes, and another way other times. One way when fulfilling one responsibility, another way when fulfilling a different responsibility. At this point you've broken your object, and it should have been two objects.
Hi Rocky,
Many thanks, that was helpful.
I agree with you that at the end it is up to us to decide what works for us, as there is no RIGHT or WRONG I guess. It depends on the context.
I think the problem I have (and a lot of other less experienced developers), is that we stop being creative and look for ALL the concrete answers.
We are the designers so it is up to us create various objects and assign them responsibilities. As long as we keep our objects happy (i.e. by assigning them few cohesive set of tasks) it does not matter whether we are doing RDD or TDD or DDD or even OO.
I would like to point out that your phrase "Normalise Behavior" has helped me a lot. It helps to create maintainable classes, although the number of classes increase but the system is clear to understand and thus maintain.
Tahir
Hi Rocky,
Some time ago, before I started this thread, I emailed Craig Larman about the assignments of responsbilities using Information Expert principal. Also I referenced your work and advice that we need to Normalize behavior rather than data. He emailed me back today with
"there are multiple guidelines for how one can assign responsibility.
Copyright (c) Marimer LLC