Start learning with our library of video tutorials taught by experts. Get started

Foundations of Programming: Object-Oriented Design
Illustration by Mark Todd

Identifying class responsibilities


From:

Foundations of Programming: Object-Oriented Design

with Simon Allardice

Video: 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.
Expand all | Collapse all
  1. 11m 35s
    1. Welcome
      1m 25s
    2. Who this course is for
      1m 15s
    3. What to expect from this course
      3m 6s
    4. Exploring object-oriented analysis, design, and development
      1m 41s
    5. Reviewing software development methodologies
      4m 8s
  2. 26m 14s
    1. Why we use object-orientation
      2m 42s
    2. What is an object?
      5m 22s
    3. What is a class?
      4m 43s
    4. What is abstraction?
      2m 45s
    5. What is encapsulation?
      3m 45s
    6. What is inheritance?
      3m 35s
    7. What is polymorphism?
      3m 22s
  3. 12m 16s
    1. Understanding the object-oriented analysis and design processes
      4m 13s
    2. Defining requirements
      6m 9s
    3. Introduction to the Unified Modeling Language (UML)
      1m 54s
  4. 23m 35s
    1. Understanding use cases
      6m 11s
    2. Identifying the actors
      4m 16s
    3. Identifying the scenarios
      5m 7s
    4. Diagramming use cases
      4m 18s
    5. Employing user stories
      3m 43s
  5. 16m 36s
    1. Creating a conceptual model
      1m 59s
    2. Identifying the classes
      2m 27s
    3. Identifying class relationships
      2m 38s
    4. Identifying class responsibilities
      6m 43s
    5. Using CRC cards
      2m 49s
  6. 22m 25s
    1. Creating class diagrams
      6m 11s
    2. Converting class diagrams to code
      4m 57s
    3. Exploring object lifetime
      5m 55s
    4. Using static or shared members
      5m 22s
  7. 19m 49s
    1. Identifying inheritance situations
      6m 49s
    2. Using inheritance
      2m 43s
    3. Using abstract classes
      2m 2s
    4. Using interfaces
      4m 20s
    5. Using aggregation and composition
      3m 55s
  8. 9m 23s
    1. Creating sequence diagrams
      5m 18s
    2. Working with advanced UML diagrams
      2m 3s
    3. Using UML tools
      2m 2s
  9. 10m 39s
    1. Introduction to design patterns
      2m 40s
    2. Example: the singleton pattern
      4m 53s
    3. Example: the memento pattern
      3m 6s
  10. 21m 47s
    1. Introduction to object-oriented design principles
      2m 50s
    2. Exploring general development principles
      3m 55s
    3. Introduction to SOLID principles
      6m 43s
    4. Introduction to GRASP principles
      8m 19s
  11. 7m 1s
    1. Reviewing feature support across different object-oriented languages
      3m 50s
    2. Additional resources
      2m 27s
    3. Goodbye
      44s

Watch this entire course now—plus get access to every course in the library. Each course includes high-quality videos taught by expert instructors.

Become a member
Please wait...
Foundations of Programming: Object-Oriented Design
3h 1m Intermediate May 22, 2012

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.

Topics include:
  • 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
Subjects:
Developer Design Patterns Programming Foundations
Software:
Java
Author:
Simon Allardice

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.

Share a link to this course
Please wait... Please wait...
Upgrade to get access to exercise files.

Exercise files video

How to use exercise files.

Learn by watching, listening, and doing, Exercise files are the same files the author uses in the course, so you can download them and follow along Premium memberships include access to all exercise files in the library.
Upgrade now


Exercise files

Exercise files video

How to use exercise files.

For additional information on downloading and using exercise files, watch our instructional video or read the instructions in the FAQ.

This course includes free exercise files, so you can practice while you watch the course. To access all the exercise files in our library, become a Premium Member.

Upgrade now

Are you sure you want to mark all the videos in this course as unwatched?

This will not affect your course history, your reports, or your certificates of completion for this course.


Mark all as unwatched Cancel

Congratulations

You have completed Foundations of Programming: Object-Oriented Design.

Return to your organization's learning portal to continue training, or close this page.


OK
Become a member to add this course to a playlist

Join today and get unlimited access to the entire library of video courses—and create as many playlists as you like.

Get started

Already a member?

Become a member to like this course.

Join today and get unlimited access to the entire library of video courses.

Get started

Already a member?

Exercise files

Learn by watching, listening, and doing! Exercise files are the same files the author uses in the course, so you can download them and follow along. Exercise files are available with all Premium memberships. Learn more

Get started

Already a Premium member?

Exercise files video

How to use exercise files.

Ask a question

Thanks for contacting us.
You’ll hear from our Customer Service team within 24 hours.

Please enter the text shown below:

The classic layout automatically defaults to the latest Flash Player.

To choose a different player, hold the cursor over your name at the top right of any lynda.com page and choose Site preferencesfrom the dropdown menu.

Continue to classic layout Stay on new layout
Welcome to the redesigned course page.

We’ve moved some things around, and now you can



Exercise files

Access exercise files from a button right under the course name.

Mark videos as unwatched

Remove icons showing you already watched videos if you want to start over.

Control your viewing experience

Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.

Interactive transcripts

Click on text in the transcript to jump to that spot in the video. As the video plays, the relevant spot in the transcript will be highlighted.

Thanks for signing up.

We’ll send you a confirmation email shortly.


Sign up and receive emails about lynda.com and our online training library:

Here’s our privacy policy with more details about how we handle your information.

Keep up with news, tips, and latest courses with emails from lynda.com.

Sign up and receive emails about lynda.com and our online training library:

Here’s our privacy policy with more details about how we handle your information.

   
submit Lightbox submit clicked