Identifying class responsibilities
Video: Identifying class responsibilitiesWe're trying to get to the point where we can truly identify what are and what aren't classes that we need to create. And much of this comes from figuring out the responsibilities of our conceptual objects, and this will be the behavior what will become methods in our objects, and here is a great starting point for this. Just as we started off by looking at the nouns in our written description to figure out our potential objects, we can go back to the use case or a user story, and look for verbs and verb phrases to pick responsibilities.
Viewers: in countries Watching now:
Most modern programming languages, such as Java, C#, Ruby, and Python, are object-oriented languages, which help group individual bits of code into a complex and coherent application. However, object-orientation itself is not a language; it's simply a set of ideas and concepts.
Let Simon Allardice introduce you to the terms—words like abstraction, inheritance, polymorphism, subclass—and guide you through defining your requirements and identifying use cases for your program. The course also covers creating conceptual models of your program with design patterns, class and sequence diagrams, and unified modeling language (UML) tools, and then shows how to convert the diagrams into code.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
Identifying class responsibilities
We're trying to get to the point where we can truly identify what are and what aren't classes that we need to create. And much of this comes from figuring out the responsibilities of our conceptual objects, and this will be the behavior what will become methods in our objects, and here is a great starting point for this. Just as we started off by looking at the nouns in our written description to figure out our potential objects, we can go back to the use case or a user story, and look for verbs and verb phrases to pick responsibilities.
So in this case, we'd have things like customer verifies items, provides payment and address, process sale, validate payment, confirm order, provide order number, check order status, and send order details email. Now, not all of these will become behaviors, some will be combined, some will need to be split apart, and some will just not be needed or be replaced by something else, but they are a good starting point, and they will often prompt others, or prompt some discussion.
So while this will provide some obvious responsibilities that need to happen, what isn't always obvious is where these responsibilities belong, particularly if they affect different objects. Because the use case here that describes them has an active perspective, but that doesn't actually work for our different objects, this is always about what initiates a behavior, not necessarily about whose responsibility it is to perform that behavior. Well, what do I mean by that? Well, let's take the idea of Check order status. It's in this use case, we pulled it out as a verb, it's reasonably obvious what this means, and almost certainly this is going to be initiated by the customer.
But the question is where would this behavior live? Whose responsibility is it to check the order status? Now, when you ask that question, the question of whose responsibility is this, always remember that an object should be responsible for itself. So even though it's the customer who wants to know the status of the order, I shouldn't write code in the customer class that messes with the inner state of an order object. The customer should really ask it of the order object. The responsibility to report its own status should live in the order object.
And this is what we mean about determining the responsibilities of our objects, not just what has to happen, but whose job it is, and this can be challenging. So, if I were to take that list that came from the use case and try to make an initial attempt to distribute them between these conceptual objects, I am likely to have a few things happen. So let's say first we look at the top one, the Verify items, and that was from the customer verifies items in shopping cart part of the use case.
We realize that's really describing a human looking at the shopping cart, and the main responsibility of the system will be to make sure all the items are presented correctly and totaled and ready to be verified. So I am actually going to make sure that the shopping cart has a Display totals responsibility. Now, the next one on the right-hand side is Provide payment and address information. Well, I've split a payment conceptual object and address conceptual object up, so I am going to split this apart into two responsibilities, and I've changed from the generic provide into Set payment details, and Set address details, because what we're talking about there was to do with entering data into the system.
Next, we have Process sale. Well, when identifying our objects earlier, I did say that sale and order refer to the same thing. So I am actually going to rename that as Process order and give that responsibility to the Order object. Again, as much as possible, an order should take care of itself. Validate payment, in this pass I will give to the Payment object. Confirm order, I will put for the Order object as we'll provide order number which I will change to Get order number, again to make that a bit more obvious what it's doing, and Check order status which just becomes the generic Get status inside the order object.
The last one here, the Send order details email, I am going to split into two parts. I will give the Order object the responsibility to construct the message, and the email object's responsibility is to send itself correctly. Now, you're probably starting to see that even this partial model could have been arranged in several different ways, and that's absolutely true. There are always multiple successful ways to implement even a simplest of ideas in Object-Orientation. Now, in this first spin, it looks like the order object has a lot of responsibilities and the customer has none.
Now, you might be wondering how that could be true, but bear in mind this is not showing who initiates these actions but where the responsibility lies in performing them. The customer is still going to be causing most of this to happen by requesting these behaviors of other objects, and it's a common mistake for people new to Object-Oriented development to give way too much behavior to an actor in a particular situation, in this case, giving say everything to the customer just because the customer is what drives this encounter.
Now, here's another issue that often comes up. It's common to see phrases like system validates payment or system will send the customer a copy of order details by email when you're looking at use cases, and that can lead to people creating a system object and putting a huge amount of responsibilities in it. But recognize that a phrase like system validates payment or system sends email is a useful lie. What it really means here of course is that some part of this system validates payment, some part of this system will send an email, and it's our job to figure out what part of the system should be responsible for that behavior.
So while there are usually built-in system or application objects in any Object-Oriented Programming language, if your own design contains a system or application or program or master object that's just been filled with lots of unrelated behaviors and seems to exist just to control everything else around, well, take care, it's often a clue that you're still thinking like a procedural programmer. Responsibilities should be distributed between your objects, not stored in one master object.
Always an object should be responsible for itself as much as possible. A little later on, we'll cover some more advanced techniques for identifying responsibilities, and some classic patterns of where they may occur, but what we've started to do is turn this from a conceptual model into an actual class diagram with behaviors, and that's really more of a subject for the next section.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.