Disclaimer: I haven’t learned Reponsibility-driven design formally, though I think that the students that I have taught, will testify that I have talked a great deal about responsibility in class design. Instead this answer draws on 25 years of experience in object-oriented design, most of it in Java.
Responsibility-driven versus object-oriented
I do to a large extent think in responsibility when designing a class (so I guess that I am doing responisibility-driven design as defined in your quotes). Ideally I think responsibility more in terms of what the instances of the class (or the class itself) can do and only secondly in terms of what data they store. This seems to agree with your second definition. In some situations I can’t uphold this ideal, though.
Putting the manipulation of data in the class where the data is (as in your first quote), I consider this a general object-oriented principle (maybe depending on which object-oriented school you subscribe to). Often expressed keep data and code together. I really don’t think that this is something specific to responsibility-driven design (but of course has its place there too).
An example. Say that a Person
object should have the responsibility of calculating a person’s age. I would consider this sound responsibility-driven design. To do this the Person
object needs the person’s birth date. To me object-oriented design would put the birth date in the Person
object so we have code and data together. This could be in contrast to for example keeping a list of birth dates. In my understanding assigning the responsibility of storing the birth dates to a separate birthday list might still be responsibility-driven, but it would not be object-oriented. This means, I don’t really agree with your first definition.
So I understand your confusion. I agree with you that the two definitions don’t say the same thing.
I am creating a distinction that in real life isn’t that clear, though. In my daily work object-oriented and responsibility-driven design go nicely hand in hand, and I don’t think consciously about the difference.
Another quote - on object-orientation
Encapsulation is a mechanism of wrapping the data (instance variables)
and code acting on the data (methods) together as a single unit like a
Class.
From OOP: Everything you need to know about Object Oriented Programming, where encapsulation is considered the first of 4 object-oriented programming concepts.
Examples of RDD from the Java standard library
I think that the following quotes from the documentation express pretty clear responsibility-driven thoughts behind the design of those interfaces and classes:
- To allow subtypes of non-serializable classes to be serialized, the subtype may assume responsibility for saving and restoring the state of the supertype's public, protected, and (if accessible) package fields. The subtype may assume this responsibility only if the class it extends has an accessible no-arg constructor to initialize the class's state. (
Serializable
)
- In practice, a button's UI takes the responsibility of calling methods on its model to manage the state, as detailed below: (
ButtonModel
)
- The PersistenceDelegate class takes the responsibility for expressing the state of an instance of a given class in terms of the methods in the class's public API. Instead of associating the responsibility of persistence with the class itself as is done, for example, by the
readObject
and writeObject
methods used by the ObjectOutputStream
, streams like the XMLEncoder
which use this delegation model can have their behavior controlled independently of the classes themselves. (PersistenceDelegate
)