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.
We're focused on the ideas and concepts of object orientation here, but we never forget that the entire point is that we'll convert this into a programming language. And it can be useful to see just how close many of the languages are with these same concepts. So I have a very simple UML class diagram here with a couple of attributes and a couple of behaviors, because I want something I can demonstrate in just a few lines of code in several different languages. So, this will be a Spaceship class. It has two attributes, one is called name which is a String, and the other is shieldStrength which I've said here will be an Integer.
Name is public and shieldStrength is private, meaning it would be hidden from other objects directly. And it has two operations, two behaviors. They're both public. Fire is going to return us a string and reduceShields returns nothing or at least nothing that's written in this diagram and takes an Integer, very straightforward, very simple. Obviously, a full spaceship class would have a lot more behaviors than this, but it will allow us to illustrate some of these concepts. So, to take this into Java, we'd have this. We use the words public class Spaceship to actually create the entire spaceship class, opening and closing curly braces to contain it.
Then we have a section called instance variables, the two Forward Slashes representing a comment. Now, from what we'd call an attribute in a generic UML diagram or a conceptual model, we're more likely to call an instance variable in this case. These are variables that belong to an instance of a class, meaning that any objects created from this class will have their own copy of these variables. I've used the words public and private to refer to the visibility level we'd selected in the diagram and those are keywords in Java.
Now, if you're unfamiliar with Java or other Curly Brace-format languages, don't worry about the syntax here. It's really just about the idea, the kind of keywords we have, the way we would name these variables, the way we would name our methods, our behaviors. Now, if I took this into C# at the same level of complexity, it would look basically identical. C# and Java are very similar, indeed, and implement a lot of these ideas the same way. We have our two instance variables, we have our two methods, one called fire that returns a string, and one called reduceShields that takes an integer called amount and returns void, meaning it returns nothing.
If I looked at this in VB.NET, it would change the format away from the curly braces. Now, we'd start to see a lot of uppercase letters at the start of our keywords just because that is the convention in VB.NET. But otherwise, it's conceptually the same. If I the look at this class in Ruby, well, Ruby also leaves out the curly braces, and it has a simpler syntax because Ruby is a dynamic language. Meaning, it does not require as much information regarding or return types. So, for example, the At sign in front of the variable names name and shield_strength is how we say these are instance variables.
Ruby's convention for naming them would be to use the Underscore between multiple words rather than an uppercase letter. Technically speaking, because Ruby is so dynamic, we wouldn't even need to declare these variables like this. We would just use them if we needed them. Now, Objective-C becomes a bit more complex, and the classes in Objective-C as in C++ are split into two pieces, what's called the interface and the implementation. These are typically held in different files.
Now, unlike the other languages we've seen up to this point, Objective-C does not use the word class here, but the @ interface and @implementation keywords. And as you can see, there's quite a bit more that it throws into the mix. The biggest difference with these kind of languages is that we have the interface that says what exists. In fact, we have the comment here that says the method declarations are here, we're saying what methods exist, fire and reduceShields. But in the other file, the implementation, is where we say how they do what they do.
And we will cover a few more things about languages later on, and I'll point you to some other resources if you're interested in a specific feature of that language.
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.