Let's say that you want to describe a family of Things that all share the same Attributes, but might have different names, colors, or other cosmetic differences.
For example, you want to describe the Vehicles that a family has in the garage. There are Attributes of each Vehicle of interest to you:
- What is the Model and Year of each Vehicle?
- How many Wheels does a Vehicle have?
- Who are the People that drive a given Vehicle?
In this case, you might have a set of two Vehicles, such that the following is true:
Vehicle A's Model is a Toyota.
Vehicle A's Year is 2001.
Vehicle A has four Wheels
Vehicle A is driven by Mom, Dad, and Junior
Vehicle B is a Moto Guzzi
Vehicle B was made in 2004
Vehicle B has two wheels
Vehicle B is driven by Dad
In various languages, you might very roughly refer the two examples in the following equivalent way:
A = new Vehicle();
A.model = "Toyota";
A.year = 2002;
A.wheelCount = 4;
A.drivers = [ "Mom", "Dad", "Junior" ];
B = new Vehicle();
B.model = "Moto Guzzi";
B.year = 2004;
B.wheelCount = 2;
B.drivers = [ "Dad" ];
In OOP, you are Encapsulating the attributes of these vehicles, so that you can describe them by their Features. Your job is to write code to get and set the values of these features (as well as do other interesting things with these features).
Further, you can "subclass", which is a way to re-use an object in different contexts. For example, you could use more specific Vehicle object types, such as Car and Motorcycle, which inherit their features from the description of Vehicle:
A = new Car();
B = new Motorcycle();
Car and Motorcycle objects are more specific descriptions of a Vehicle. These two subclasses can have their own special attributes. A Car might have Childproof Locks, whereas a Motorcycle would generally not have such need for a thing.
Instead of setting the Childproof Lock attribute of a Vehicle, you can say that only a Car has a Lock attribute. This makes your Vehicle description cleaner and easier to write and maintain.
