When programming, or solving any sort of problem for that matter, abstraction plays a key role in the decision-making process. It allows you to remove irrelevant details in order to understand the bigger picture.
For example, if you were constructing a program to inventory cars for sale at a used car lot, it would not make much sense to design a unique class for each separate car, especially if there are many vehicles in the lot. Instead, you would create a single "Car" class and personalize it for each vehicle.
Abstraction plays a key role in object-oriented programming. As the designer, you decide which characteristics are (and which are not) important as you define classes. In the context of the used car lot example, you could consider separate subclasses of the Car class for each make of car. Ordering classes hierarchically can save you time and effort.
For instance, a Corolla and a Camry are individual models of cars, but they both inherit certain characteristics from their shared make, Toyota.
However, hierarchies present their own challenges. Just because you can construct hierarchies, it does not necessarily mean that it is useful to do so. Consider the Unified Modeling Language (UML) class diagram below, which contains a set of subclasses for the superclass Car. In this chart, the "Car" class has characteristics for the color and registration number for the car. Stemming from the "Car" class are 3 subclasses, Ford, Volvo, and Toyota, which are for different car manufacturers.
In this case, creating separate subclasses of Car is more trouble that it is worth, because the inventory program probably does not have to treat different models of cars in different ways.
Therefore, it is probably more appropriate simply to designate the make of the car in a field of the class, as illustrated in the UML class diagram below. For this chart the "Car" class still has the color and registration number as characteristics.
However, the subclasses have been removed, and instead there is another characteristic of the "Car" class called "type" that accounts for the make of the car.
The larger question at play is this: "What characteristic of an object is significant enough to warrant a subclass rather than simply data in a field?" Think about an application in your field of expertise and the classes that you would define for that application.
Post a response that describes the application you choose and the class within that application.
Identify one or two key distinctions within that class that would prompt you to create subclasses instead of fields within the main class.
Explain your reasoning, giving specific examples of objects in each of the classes and subclasses you discuss, and draw a UML class diagram to support your claim.