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 we need those concepts and that vocabulary. But how do we make decisions about polymorphism and inheritance without actually knowing what our classes and objects are? Well, we need to go through a process to identify the classes for our application. Now whether you use a formal software development methodology or not, this is the entire point of object-oriented analysis and design, what classes do you need and what do they do? Now a lot of the formal methodologies have their own unique names for working through their process, but although there are multiple ways to approach this, the ideas are fairly similar, and we'll go through a typical approach using five steps.
One, gather your requirements. Two, describe the application. Three, identify the most important objects. Four, describe the interaction between those objects. And five, create a class diagram. Now we're going to talk about all of these in more detail, and we'll cover techniques you use for each step. But let's take it one level deeper right now. Step one is gathering your requirements. What does the app need to do? What problem are you trying to solve? And you focus here, you get specific, and you write it down, because that's the only way you're going to get past the conflicting and half-formed ideas people have about what this app could do versus what the app is going to do.
Step two is you then describe the application, you build a simple narrative in plain conversational language for how people use the app. You're not trying to write a book, but you are trying to describe in small self-contained pieces, and there are some specific techniques for this, including use cases and user stories, which we'll talk about shortly. Now this is not exhaustive, you're looking for the smallest set of stories that will make this a real application. We're going to make the assumption that what we have here may be inaccurate, it may be incomplete, it may change. That's okay. We still do it.
Now you may or may not at this point also create a mockup or a prototype of the user interface. Sometimes that is essential and sometimes it's just a distraction. We move on to step three, identifying the most important objects. Now this is actually the starting point of identifying your actual classes. So you're trying to use the stories, the descriptions you just wrote to pick out the most important ideas, the most important concepts, the most important things in our application and discard what's around it.
Not everything we pick here will become a class, but a lot of them will. Step four is you then formally describe the interactions between those objects, our customer needs to open a bank account, a spaceship needs to explode when it touches an asteroid. Now this also lets you start to better understand the responsibilities of the different objects, the behaviors they need to have. And when they interact with other objects, what they do and what order they need to do it in. And one way to do this is what's called a sequence diagram.
And step five is Create a Class Diagram. This is a visual representation of the classes you need. And here is where you get to be really specific about object-oriented principles like inheritance and polymorphism. But at no point in any of this do you write code yet. The output is on paper, on index cards, on a whiteboard. It could be done using electronic tools, but it's really better on paper for now. And the main result you expect from the process is the Class Diagram.
That's the most common way you'll write down the classes you need to make, the methods in those classes, and the interaction between the different objects in your application. Now in an iterative approach to developing software, this is not done once, you will continually revisit and refine these steps over weeks and months of development. So we are going to cover these steps in much more detail, including how to create all the diagrams I've already mentioned. But first, we need to get specific about the requirements of our application.
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.