What is a class?
Video: What is a class?Objects and classes go hand in hand. We can't talk about one without talking about the other. And the entire point of Object-Oriented Design is not about objects, it's about classes, because we use classes to create objects. So a class describes what an object will be, but it isn't the object itself. A class is a blueprint, a detailed description, a definition. The blueprint example is a good one. If you want to build a house, you make a blueprint first.
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.
- Why use object-oriented design (OOD)?
- Pinpointing use cases, actors, and scenarios
- Identifying class responsibilities and relationships
- Creating class diagrams
- Using abstract classes
- Working with inheritance
- Creating advanced UML diagrams
- Understanding object-oriented design principles
What is a class?
Objects and classes go hand in hand. We can't talk about one without talking about the other. And the entire point of Object-Oriented Design is not about objects, it's about classes, because we use classes to create objects. So a class describes what an object will be, but it isn't the object itself. A class is a blueprint, a detailed description, a definition. The blueprint example is a good one. If you want to build a house, you make a blueprint first.
It describes everything about how that house will be built, but it isn't the house. You then use that blueprint to build the house. For us, we write the class then use the class to create the object. And just as we could use the same blueprint to build one, two, or a hundred houses, we can define the class once and then create a thousand objects based on that one class, but the class comes first. The class comes first, that's what we write.
So a class has a name. Literally, what is it? And it describes two things: attributes and behavior. What attributes, what pieces of information will describe each object, and what can each object do? Now you might see other somewhat interchangeable terms for these words. Instead of name, we might say type. We create objects of a particular type. For attributes you might also see them referred to as properties or just generically as data, and behavior is also referred to as operations.
Again, what operations does this class have? What can it do? Now when we actually write this behavior in code, we will typically call it a method. Now if you come from a non-object- oriented language where you're familiar with functions, you can think of methods as simply being functions that belong to a class. There are blocks of code that can be called, can perform actions, and return values. So here is an example. If your application deals with banking, you might create a bank account class, and the class would be called BankAccount, and it will then have attributes to it.
The class says that each object has an accountNumber, but it doesn't say what the account number is. It says each object will have a balance, but it doesn't say what that balance is. It's just providing the definition. And behavior might say we have got open, closed, and deposit and withdraw. You will often see a diagram that looks something like this to sketch out a class, the name, the attributes, the behavior. Now we will go more into these diagrams later. But after writing the class, we can then create objects based on that class.
The other term that we use is we are creating instances of a class, each object is an instance of a particular class. And actually, the process of creating these objects is called instantiation. Now each instance, each object-- whether one, two, or a thousand--has its own identity independent from other objects and its own data and its own behavior. So the class says that each object has a balance, but the individual objects say, well, my balance is 500 or -50 or 7500.
We can deposit to one account object and withdraw from another account object, and each behavior is independent. So if we want to create objects, we need the class first, and if we haven't written the class ourselves, someone else needs to have written it already. Now in most Object-Oriented languages there are a lot of classes are already written for you that come along with the language so you can start creating objects without writing your own classes. First, basic useful things like strings and dates and arrays are often written as pre-provided classes so that you don't have to begin each program by writing the same classes over and over again.
These classes are written and then gathered together into frameworks or libraries. In Java you have the Java Class Library, about 4000 classes available to you. And the .NET Framework for C# and VB.net has even more than that. C++ has the C++ Standard Library. Ruby also calls its default library the Standard Library, as does Python. But even though we might have a lot of classes available to us in any non-trivial application, we will still need to write our own classes.
And to be able to write our own and write them well, we have a few more principles to keep in mind.
There are currently no FAQs about Foundations of Programming: Object-Oriented Design.