Concrete Class
An object in a computer program can be loosely defined as something that represents a "thing," like a car or a motorcycle. Objects have states (is the engine running or is it off?), identities (what make is this car?), and behaviors or functions (turn the wheels, accelerate, etc.).
What this means in real terms is that there is a collection of data and functions in the computer program associated with some logical item that represents a thing in the real-world. The type of an object, generally named in some way after what the object represents, is usually called its "class."
A class is a description or template that describes how to build and use an object. An object created from a class description is said to be an "instantiation" or "instantiated object" of that class. A "concrete class is a class from which it is possible to instantiate objects. In comparison, it is not possible to create objects of an "abstract class."
For example, a software package for simulating passenger vehicles might have many pre-defined vehicles in it, such as cars, motorcycles, ships, airplanes, and so on. Thus, an object of the class "motorcycle" might represent a motorcycle.
When the program user adds a motorcycle to the program, there is (somewhere in the program) a block of memory that represents what the vehicle is and what it can do. In this case there is an instantiated object of a "motorcycle" in the computer program, and its data might contain information about how big its engine is, what color its tank is, and how many wheels it has; and its methods might include functions that allow it start and stop its engine, steer its front wheel, and add fuel to the tank.
If other vehicles are considered it becomes clear that they will all share some common attributes and functions: they will all be of some color and they will all need to have some method of propulsion, for example. Other attributes and functions will be unique to each type of vehicle: a ship does not have wheels and a motorcycle does not have lifeboats.
In an object-oriented design it would make sense to have a general class called a "vehicle" that contains the data and functions that are common to all types of vehicle; it would then make further sense to have classes derived from the "vehicle" class contain the unique data and functions particular to its class. These "derived classes" are said to "inherit" the general characteristics from its parent class, or "base class."
It follows then that it doesn't make sense to try to instantiate an object and call it a "vehicle" object, since there is no such concrete thing as a "vehicle": "vehicle" is an idea, an abstract concept. What kind of vehicle is it? Does it have wheels? Does it have lifeboats? How does it move? How does it steer? These are all questions that will have different answers for different vehicles.
It is likely that in such an object-oriented design there would be a rich hierarchy of vehicles derived from the base class, such as "wheeledVehicle," which would also be an Abstract Class, and the class "Motorcycle" would be derived from this rather than directly from "Vehicle."
In the class hierarchy above, then, the classes "Vehicle" and "wheeledVehicle" would be "abstract base classes" and the "motorcycle" classes derived from them would be "concrete classes," precisely because it is possible to create objects of that type.
This is the complete article, containing 572 words
(approx. 2 pages at 300 words per page).
