Start learning with our library of video tutorials taught by experts. Get started
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.
So step 1, what we do is collect our Use Cases, our User Stories, and any other written requirements together. And here's where we have one of the greatest benefits of having these written descriptions of our application. We just go through them and start picking out all the nouns. Just start highlighting or underlining, and make a list of them. Because these are your possible objects, your candidate objects. Now when we're gathering, we don't analyze or judge them here. We don't worry if there's a better word to use or if we perhaps used the different noun to describe the same thing on another card.
We just start making the list. We also don't worry we might miss one, it happens. Just take a first run through picking out all the nouns. So I've done them here just on this single casual Use Case to create a partial model, and you'll end up with a list of nouns, potential objects. You can then first take a pass through this and find if there's any obvious duplicates. From my application I referred to the word Sale and the word Order to mean exactly the same thing, so I'll get rid of one of them.
Quite often you'll find yourself combining some of these or even splitting some of them. Picking out the nouns is merely a starting point. Now sometimes what you'll find is that attributes are going to announce themselves at this point. So we look at Order Number and realize this really only makes sense as part of the order concept. So it would be an attribute of an Order class. It's part of an order. But when I focused on showing that kind of data right now, so we can just remove that one. And the same way the Order Details, as far as my Use Case was concerned, this just meant a description of the order, not a separate thing.
So I'll remove that too. Along with Order Status. And although System was used as a noun, I'm going to remove that, too, and I'll get into the reason why a little later on. So we're left with a handful just from this one casual Use Case. Now optionally we can make a quick diagram of these. As always diagrams aren't necessary, but they can be useful. And this is very simple. We just box all the objects. This is the beginning of it. And the conceptual model, we're not turning these yet into full class diagrams, so there are no formal method names and attributes.
We're just using the names of the objects. The benefit of creating a diagram is that it becomes easier to show the responsibilities and the relationships between the different objects as we start to build this out.
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.