I love reading the book Code Complete, by Steve McConnell. The following comes from it.
In designing a software system, you’ll often find objects that are much like other objects, except for a few differences. In a accounting system, for instance, you mights find both full-time and part-time employees. Most of the data associated with both kinds of employees is the same, but some is different. In object-oriented programming, you can define a general type of employee and then define full-time employees as general employees, except for a few differences, and part-time employes also as general employees, except for a few differences.
When an operation on an employee doesn’t depend on the type of employee, the operation is handled as if the employee were just a general employee. When the operation depends on whether the employee is full-time or part-time, the operation is handled differently.
Defining t and differences among such objects is called “inheritance” because the specific part-time and full-time employees inherit characteristics from the general-employee type.
The benefit of inheritance is that it works synergistically within the notion of abstraction. Abstraction deals with objects at different levels of detail.
Inheritance simplifies programming because you write a general routine to handle anything that depends on general properties and then write specific routines to handle specific operations…
The ability of a language to support operations [..] without knowing until run time what kind of .. object .. you are dealing with is called “polymorphism”.
Inheritance is one of object-oriented programming’s most powerful tools. It can provide great benefits when used well, and it can do great damage when used naively.