Start learning with our library of video tutorials taught by experts. Get started
Viewed by members. in countries. members currently watching.
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.
We've already seen what are referred to as Associations in a diagram. Drawing any kind of line between objects simply suggests there is some kind of interaction. One object knows about or interacts with a different object. We can add a note to explain this, it might just be that one object is calling a method of another object. But we can get more specialized with what we're trying to illustrate. We've seen the way already that we show Inheritance with the empty arrow pointing at the superclass or parent class.
And we have another couple of terms here to explore and their supporting diagrams. We are going to talk about aggregation and composition, both are very long words for simple ideas. And they describe an obvious relationship between our objects that one object can often be built of other objects. So Aggregation is often referred to as a HAS A relationship as opposed to the IS A relationship of Inheritance. We would never say something like a customer is a address, but we might say a customer has a address or a car has a engine.
Well, correctly I'd say a car has an engine, but this will work. Now HAS A can implicitly suggest HAS MANY, so a bank has many bank accounts or a university has many students. But what we're exploring is the HAS A relationship not the IS A relationship. In UML we can display it like this, there is an official diagram for the HAS A aggregation, it's the unfilled diamond. So, for example, we might have a classroom object that will contain an array of student objects that might be important to diagram that relationship.
In this case we'd read it as a classroom has a student, potentially classroom has many students. So as with other diagrams we can optionally have a multiplicity indicated to say that one classroom can have--and we use the Asterisk to represent zero to many students. This is aggregation, and it's very common, and to be honest it's not always worth showing it on a class diagram unless there is something interesting or unusual about it, but you will see this empty diamond, and that's what it means.
Now Composition is also Aggregation, Composition is a more specific form of Aggregation. And it implies ownership, now what does that mean? Let's say we have a Document class and a Page class, and what we imagine is that a Document object will be composed of Page objects, made up of page objects, this is Composition. Now what's the difference between Aggregation and Composition or Composition implies ownership. And what that means is when the owning object is destroyed so are the contained objects.
It's still a HAS A relationship here, Document has a Page or has many pages. But if I were to delete the Document object all the associated Page objects should be deleted too. I would not expect then those page objects to be shared with any other part of the application. On the other hand in a plain aggregation situation as with the Classroom and Student relationship, if I deleted the Classroom object, perhaps the class got canceled, I would not expect all the Student objects to be destroyed, they may be used in different classrooms or just be able to live on their own.
And that's the difference, Composition implies ownership, Aggregation does not. Now Aggregation is not usually worth showing on a diagram, but Composition often can be. If the lifetime of an object is dependent on another object existing that can be worth showing, even if we are just prompting the idea that when you're defining the owning class, say here the Document class, you may need to write a constructor and a destructor that would take care of creating and/or deleting the internal objects.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.
Access exercise files from a button right under the course name.
Search within course videos and transcripts, and jump right to the results.
Remove icons showing you already watched videos if you want to start over.
Make the video wide, narrow, full-screen, or pop the player out of the page into its own window.
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.