In object-oriented programming, a class is a template definition of the method s and variable s in a particular kind of object. Thus, an object is a specific instance of a class; it contains real values instead of variables.
The class is one of the defining ideas of object-oriented programming. Among the important ideas about classes are:
- A class can have subclasses that can inherit all or some of the characteristics of the class. In relation to each subclass, the class becomes the superclass.
- Subclasses can also define their own methods and variables that are not part of their superclass.
- The structure of a class and its subclasses is called the class hierarchy.
In Object Oriented Programming, a Class is a blueprint for an object. In fact, classes describe the type of objects, while objects are usable instances of classes. Each Object was built from the same set of blueprints and therefore contains the same components (properties and methods). A class can have any number of properties and methods to access the value of various kinds of methods.
In real life, similar objects can be grouped based on some criteria. For example A Ford car and a Toyota car are both Cars, so they can be classified as belonging to the Car class. There may be thousands of other Cars in existence, all of the same make and model. Each Car was built from the same set of blueprints and therefore contains the same components. In object-oriented terms, we can say that your car is an object (instance) of the class known as CAR. You can create different objects using the same class, because a class is just a template, while the objects are concrete instances, based on the template.
In the real world, you often have many objects of the same kind. For example, your bicycle is just one of many bicycles in the world. Using object-oriented terminology, we say that your bicycle object is an instance of the class of objects known as bicycles. Bicycles have some state (current gear, current cadence, two wheels) and behaviour (change gears, brake) in common. However, each bicycle’s state is independent of and can be different from other bicycles.
When building bicycles, manufacturers take advantage of the fact that bicycles share characteristics by building many bicycles from the same blueprint–it would be very inefficient to produce a new blueprint for every individual bicycle they manufactured.
In object-oriented software, it’s also possible to have many objects of the same kind that share characteristics: rectangles, employee records, video clips and so on. Like the bicycle manufacturers, you can take advantage of the fact that objects of the same kind are similar and you can create a blueprint for those objects. Software “blueprints” for objects are called classes.
The values for instance variables are provided by each instance of the class. So, after you’ve created the bicycle class, you must instantiate it (create an instance of it) before you can use it. When you create an instance of a class, you create an object of that type and the system allocates memory for the instance variables declared by the class. Then you can invoke the object’s instance methods to make it do something. Instances of the same class share the same instance method implementations (method implementations are not duplicated on a per object basis), which reside in the class itself.
In addition to instance variables and methods, classes can also define class variables and class methods. You can access class variables and methods from an instance of the class or directly from a class–you don’t have to instantiate a class to use its class variables and methods. Class methods can only operate on class variables–they do not have access to instance variables or instance methods.
The system creates a single copy of all class variables for a class the first time it encounters the class in a program–all instances of that class share its class variables. For example, suppose that all bicycles had the same number of gears. In this case, defining an instance variable for a number of gears is inefficient–each instance would have its own copy of the variable, but the value would be the same for every instance. In situations such as this, you could define a class variable that contains the number of gears. All instances share this variable. If one object changes the variable, it changes for all other objects of that type.
Objects vs. Classes
You probably noticed that the illustrations of objects and classes look very similar to one another. And indeed, the difference between classes and objects is often the source of some confusion. In the real world it’s obvious that classes are not themselves the objects that they describe–a blueprint of a bicycle is not a bicycle. However, it’s a little more difficult to differentiate classes and objects in software. This is partially because software objects are merely electronic models of real-world objects or abstract concepts in the first place. But it’s also because many people use the term “object” inconsistently and use it to refer to both classes and instances.In the figures, the class is not shaded because it represents a blueprint of an object rather than an object itself. In comparison, an object is shaded, indicating that the object actually exists and you can use it.
The Benefit of Classes
Objects provide the benefit of modularity and information hiding. Classes provide the benefit of reusability. Bicycle manufacturers reuse the same blueprint over and over again to build lots of bicycles. Software programmers use the same class, and thus the same code, over and over again to create many objects.