Identifying class relationships
Video: Identifying class relationshipsOnce we have a simple conceptual diagram together, it's useful to indicate the main relationships--also referred to as associations--between these concepts by just drawing lines between the boxes. Now many of these will be obvious. But we can also go back to the Use Cases and User Stories to verify what was written. So in my case, I know the idea or concept of a Customer had some kind of relationship, interaction with the shopping cart. The Shopping Cart could be filled with items. The Order is also made of items.
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 relationships
Once we have a simple conceptual diagram together, it's useful to indicate the main relationships--also referred to as associations--between these concepts by just drawing lines between the boxes. Now many of these will be obvious. But we can also go back to the Use Cases and User Stories to verify what was written. So in my case, I know the idea or concept of a Customer had some kind of relationship, interaction with the shopping cart. The Shopping Cart could be filled with items. The Order is also made of items.
There's a relationship between the Customer and the Order because they're the one who places it, and not surprisingly the Order needs Address information, and also Payment information and so on. I'm not even trying to describe every single possible connection, just the most interesting ones. Now optionally, it maybe useful to add a short note to actually describe the relationship. That could be something as simple as say the word Users like the Customer uses the Shopping Cart. Although uses is a little generic, it's better to have more specific terms.
So rather than say Order uses Payment, we have Order paid by Payment. Shopping Cart contains Item, Customer places Order, Order contains shipping information and so on. Optionally, you can add some symbols to describe a little bit more about the relationship. Say the Shopping Cart can contain multiple Items. We can describe it using this kind of format here. One Shopping Cart contains many Items. This is indicating what's called multiplicity.
Now it's not necessary to write this, but again it can be useful. The key question is always is it interesting and/or important enough to need to be put on the diagram. Remember this is a conceptual diagram. We're not building software right off this, we're using it for communication, we're using it to prompt some ideas for us. And just a quick word of warning, if you have any database design background, be careful. It's very easy for people who have done relational database work to find themselves unconsciously trying to diagram Foreign Keys and Primary Keys, and creating many-to-many relationships.
We are not doing database data modeling here, we're doing conceptual object modeling, and that's a very different process. The benefit of detailing these relationships is it makes it a little easier to realize which objects interact with each other, meaning which objects have behavior that affect other objects. And figuring out our object's main behavior, their responsibilities, is the next step.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.