One of the most difficult parts of the object-oriented design process is trying to identify the classes that you will need to model a domain, what the relationships
between those classes should be, and how objects of those classes will interact with one another at runtime. Even the most knowledgeable object-oriented
developers rarely get it all right the first time. Often developers new to Object-Oriented Programming (OOP) are troubled by this, fearing the long-term consequences of early design mistakes. Fortunately, the use of good encapsulation and implementation hiding techniques should minimize the “ripple effects” normally associated with changing modularized code.
Nevertheless, certain changes force us to look at the problem domain in a whole new way. Here, for instance, you may discover that your original design was not
sophisticated enough to handle specialized cases. Frequently, during gap analysis, you may realize that you have either failed to identify certain classes in the
domain or that you have defined particular classes too generically.
For example, let’s say you take a first pass through a set of requirements for a human resources system. During this analysis process, you discover a need for an Employee class, among others. However, during the implementation cycle of the project, more requirements come out that describe specific functionalities relevant for certain types of employees. At this point, you could try and enhance the original Employee class to deal with these added features, but this seems counterintuitive because it clutters the class with too many responsibilities. On the other hand, abandoning the Employee class altogether in favor of a series of specialized classes (e.g., HourlyEmployee, etc.) leads to the kind of code redundancy issues that you want to avoid. Fortunately, object-oriented languages such as ABAP Objects provide a better and more natural way for dealing with these kinds of problems.
The concept of inheritance can be used to extend a class so that you can reuse what is already developed (and hopefully tested) to expand the class metaphor to better fit specialized cases. The newly created class is called a subclass of the original class; the original class is called the super class of the newly created class. As the name suggests, sub classes inherit components from their super class. These relationships allow you to build a hierarchical inheritance tree with super classes as parent nodes and sub classes as child nodes .