I am very confused about the responsibility-driven design concept. Mainly because of ever so slightly changing definitions depending on the source.
Quoting BlueJ (the book I am learning that teaches Java):
Responsibility-driven design expresses the idea that each class should be responsible for handling its own data. Often, when we need to add some new functionality to an application, we need to ask ourselves in which class we should add a method to implement this new function. Which class should be responsible for the task? The answer is that the class that is responsible for storing some data should also be responsible for manipulating it.
Later, in a "concept box" in the BlueJ book:
Reponsibility-driven design is the process of designing classes by assigning well-defined responsibilites to each class. This process can be used to determine which class should implement which part of an application function.
This second definition confuses me, as I don't see how that correlates to the first "definition"; the one saying that "it expresses the idea that each class should be responsible for handling its own data".
Will someone please shed some light on the concept of responsibility-driven design?
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.
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:
Serializable)ButtonModel)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)