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.
The information that you have now should be enough to let you create your first collection of classes. And the most common way to jot these out is with a UML class diagram, and we've seen these once or twice already. These are the most common diagram in Object-Oriented Design, and while they can get advanced, we're going to focus here on the most common that you'll see and use. So, we want a list of classes, and we'll create a class diagram for each, and for each class we'll have the primary attributes and primary operations. And at this point, because we're getting closer to the code, we will pay more attention to naming.
So, our classes are named in the singular, not plural, and the standard is for an uppercase first letter, so employee, event, customer, image, product. Now, with Attributes, you won't know all of them yet, because we've been focusing on the behavior, on the operations, but you're expecting to just initially write down the obvious ones, and again, we can add more once we start programming. As I'll talk about in a moment, attributes are usually a lot easier to determine than behaviors. So we'll start to name these using whatever naming format is typical for your language.
I'm going with the common Pascal Case, lowercase first letter, uppercase each following word. And obviously this is an incomplete class diagram, we've got some basic data, a product has a name, it has an isActive flag that can be true or false, it will have a launchDate and say an itemNumber. Now, it's perfectly common just to see the names of the attributes but you can also see them written with a suggested data type after a Colon. So :String for name :Boolean for the isActive flag, :Date, :Integer, but you don't have to go to this level of detail.
Now, if your language names their data types differently, it doesn't really matter. It's all about making this readable and understandable. Say in Objective-C, I might know that I'd need to implement this name attribute as an NSString object, but I don't have a problem reading the fact that it's a string. We can also describe a default value when necessary using an equal sign after the data type. And again, these aren't needed on all of them, just the ones where it's relevant and important. Then we come down to the Operations section where we should have a good idea of what we need to write down here if we've done any work with conceptual object models or CRC cards.
We'll start to name them. I am just going to go with the same case format, lowercase first letter, and uppercase every subsequent word. If we know we need some methods to modify and retrieve attributes, we typically name them as Get and Set operations, rather than change or retrieve. And this is one of the few cases where if you know your particular language automatically generates Getter and Setter methods, this might be a little different for you. Now, as we're going to turn these into code, it's quite common to see parentheses containing any parameters.
And in this case, the only one I've put that actually has a parameter is the Boolean that's passed into setActive. But on the other side, we can also add a return type, and the way we write this in a UML class diagram is to put a Colon after the parentheses and just the return type I am expecting to come back from this operation. These classes are likely to have a lot more functionality internally, but because we've been focusing on the actual responsibilities of the objects, we're really focused first on the public visibility. What are the operations that other objects need to know about? Now, if you remember in our discussion of encapsulation, I talked about trying to hide as much of the implementation as possible and only share what was absolutely necessary to expose.
And when drawing diagrams, it's common to see signs before the attributes or methods, most common is a Plus sign or Minus sign, so I've put several Minus signs in front of the attributes here. This is referred to as controlling visibility, and Minus means these should be private to the class, not directly accessible from other objects. So I can see here that I'm saying my name attribute is private, but I do have a getName operation which will be public and marked with a Plus sign, and that returns a string.
I might say here that in the operations I've drawn out, I know that formatProductDetails is only going to be used internally within the object, so I've made that one private and the others all public. Now, there are other signs, but the Plus and Minus are the two most important. And again, the rule is to leave as much private as possible, and only make it public if you know another object has to use this attribute or method. You can also add notes to a class diagram when necessary if you want to add a bit more information. The usual format looks like this, note has the top-right corner folded down so that we don't think this box represents another class.
It's often very tempting for programmers to actually begin with these kinds of diagrams. You might think you should start here and just begin by charting out your classes as completely as you can, but there's a reason I favor the concentration on responsibilities and doing some of the work with use cases and user stories and conceptual models, and that's if you jump straight to object creation, what often happens is people focus on the data. They decide they need to build a customer object and an order object, but the way they start to be built is that the customer has customerId, customerName, an email, address, a phone, a company, the obvious attributes, same with Order, it will have orderNumber, orderDate.
And if you find yourself defining classes that are strangely devoid of any behavior at all, you might want to revisit those responsibilities, because it's true that these objects may need these attributes, but it's the wrong initial focus, and when you take the responsibility focus, do a little work with requirements, written descriptions, and conceptual models or CRC cards, your focus is on what the objects do, not just viewing them as dumb data structures. So a little later, we're going to see how to show associations between multiple classes.
But let's first see how we might transform some of these diagrams into code.
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.