- To solve the final challenge of identifying class relationships, we'll begin by looking for classes that have similar attributes or methods. The first thing I notice is that the User and Admin classes both have an 'id' attribute and a 'getId' method. This is a hint that there might be an opportunity for inheritance here. So, to test that idea, just ask if the phrase 'User is a Admin' makes sense. - [Olivia] Well, a User could be an Admin. That's not always the case.
- [Man] Then how about 'Admin is a User'? - [Olivia] That makes more sense. An admin is a type of user with extra capabilities. So, in this case, User can act as the super class which the Admin class can inherit from. Notice we've removed the id attribute and 'getId' method for the Admin class in this diagram since they'll be inherited from the user. Using inheritance here could come in handy down the road if we decide to implement additional types of special users. - Like a musical curator who updates the songs to keep them fresh.
- Then, that curator could automatically have the User id if it inherits from the user class. - [Man] Great. I also noticed that the Library and Album classes have the same title and getTitles attribute and method. So this could be another inheritance opportunity. - [Olivia] Does 'Library is an Album' make sense? - [Man] Uh, nope. - [Olivia] What about 'Album is a Library'? - Eh, that's not any better. So there's not a straightforward way for one of these classes to inherit from the other. But, I still think there's a relationship here since a Library and an Album both represent a collection of things.
So, I'll pull out those commonalities to create a new collection class and let both the Library and Album class inherit from it. Bam! Inheritance. - You know, while that will technically work, I think you may have gone a little too far with the abstraction this time. I don't foresee us creating any other classes that will need to inherit from that particular collection class. So all you've really done is turn two classes into three which makes things unnecessarily confusing. - But, inheritance-- - Isn't always the right thing to do.
It depends. - Arguments like this are common when programmers work together and, as with all of our arguments, Olivia wins. We won't use inheritance there. - [Olivia] Although I don't think we should use inheritance with the Library and Album classes, recognizing that they both represent a collection of things is useful because they suggest an aggregation relationship. The Library is an aggregation of one or more albums, and along those lines, an album is the aggregation of one or more songs.
- [Man] But the aggregations don't stop there. A queue is also an aggregation of songs, but since the play queue can be empty, it's an aggregation of zero or more songs. Putting it all together gives us our final class diagram. The output of our object-oriented design process, and it's something we can actually use to start writing code. - But that doesn't mean this diagram is finished and set in stone. I'm sure as we start turning this into actual code, we'll discover new problems and have to make changes. But these diagrams give us the starting point we need to begin implementation.
- Object-oriented basics: objects, classes, and more
- Defining requirements
- Identifying use cases, actors, and scenarios
- Domain modeling
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Developing software with object-oriented design principles