- 4.1 Introduction
- 4.2 Classes, Objects, Methods, Properties and Instance Variables
- 4.3 Declaring a Class with a Method and Instantiating an Object of a Class
- 4.4 Declaring a Method with a Parameter
- 4.5 Instance Variables and Properties
- 4.6 UML Class Diagram with a Property
- 4.7 Software Engineering with Properties and set and get Accessors
- 4.8 Auto-Implemented Properties
- 4.9 Value Types vs. Reference Types
- 4.10 Initializing Objects with Constructors
- 4.11 Floating-Point Numbers and Type decimal
- 4.12 Wrap-Up
- Summary
- Terminology
- Self-Review Exercises
- Answers to Self-Review Exercises
- Exercises
- Making a Difference Exercises
This chapter is from the book
This chapter is from the book
This chapter is from the book
4.2 Classes, Objects, Methods, Properties and Instance Variables
Let's begin with a simple analogy to help you understand classes and their contents. Suppose you want to drive a car and make it go faster by pressing down on its accelerator pedal. What must happen before you can do this? Well, before you can drive a car, someone has to design it. A car typically begins as engineering drawings, similar to the blueprints used to design a house. These engineering drawings include the design for an accelerator pedal to make the car go faster. The pedal "hides" the complex mechanisms that actually make the car go faster, just as the brake pedal "hides" the mechanisms that slow the car and the steering wheel "hides" the mechanisms that turn the car. This enables people with little or no knowledge of how engines work to drive a car easily.
Unfortunately, you can't drive the engineering drawings of a car. Before you can drive a car, it must be built from the engineering drawings that describe it. A completed car will have an actual accelerator pedal to make the car go faster, but even that's not enough—the car will not accelerate on its own, so the driver must press the accelerator pedal.
Methods
Now let's use our car example to introduce the key programming concepts of this section. Performing a task in an application requires a method. The method describes the mechanisms that actually perform its tasks. The method hides from its user the complex tasks that it performs, just as the accelerator pedal of a car hides from the driver the complex mechanisms of making the car go faster.
Classes
In C#, we begin by creating an application unit called a class to house (among other things) a method, just as a car's engineering drawings house (among other things) the design of an accelerator pedal. In a class, you provide one or more methods that are designed to perform the class's tasks. For example, a class that represents a bank account might contain one method to deposit money in an account, another to withdraw money from an account and a third to inquire what the current account balance is.
Objects
Just as you cannot drive an engineering drawing of a car, you cannot "drive" a class. Just as someone has to build a car from its engineering drawings before you can actually drive it, you must build an object of a class before you can make an application perform the tasks the class describes. That's one reason C# is known as an object-oriented programming language.
Method Calls
When you drive a car, pressing its gas pedal sends a message to the car to perform a task—make the car go faster. Similarly, you send messages to an object—each message is known as a method call and tells a method of the object to perform its task.
Attributes
Thus far, we've used the car analogy to introduce classes, objects and methods. In addition to a car's capabilities, it also has many attributes, such as its color, the number of doors, the amount of gas in its tank, its current speed and its total miles driven (i.e., its odometer reading). Like the car's capabilities, these attributes are represented as part of a car's design in its engineering diagrams. As you drive a car, these attributes are always associated with the car. Every car maintains its own attributes. For example, each car knows how much gas is in its own gas tank, but not how much is in the tanks of other cars. Similarly, an object has attributes that are carried with the object as it's used in an application. These attributes are specified as part of the object's class. For example, a bank-account object has a balance attribute that represents the amount of money in the account. Each bank-account object knows the balance in the account it represents, but not the balances of the other accounts in the bank. Attributes are specified by the class's instance variables.
Properties, Get Accessors and Set Accessors
Notice that these attributes are not necessarily accessible directly. The car manufacturer does not want drivers to take apart the car's engine to observe the amount of gas in its tank. Instead, the driver can check the fuel gauge on the dashboard. The bank does not want its customers to walk into the vault to count the amount of money in an account. Instead, the customers talk to a bank teller or check personalized online bank accounts. Similarly, you do not need to have access to an object's instance variables in order to use them. You can use the properties of an object. Properties contain get accessors for reading the values of variables, and set accessors for storing values into them.