Java - Definition of Inheritance Object Oriented Programming

Definition of Inheritance:-

Inheritance is the process of sub-classing that we can create a child-class from a parent-class. Java programming language permits single inheritance, because in Java a class can extend one other class only. A child-class can inherited all of the members from the parent-class, but it does not inherit the constructor.

Subclasses and Superclasses:-

A subclass, heir class, or child class is a modular, derivative class that inherits one or more properties from another class (called the superclass, base class, or parent class). The properties in question vary from language to language, but commonly include class data variables, properties, and methods or functions. Some languages support the inheritance of other properties as well. For example, in Eiffel, contracts which define the specification of a class are also inherited by heirs. The superclass establishes a common interface and foundational functionality, which specialized subclasses can inherit, modify, and supplement. The software inherited by a subclass is considered reused in the subclass.

In some cases, a subclass may customize or redefine a method inherited from the superclass. A superclass method which can be redefined in this way is called a virtual method.

Roles and Inheritance:-

Sometimes inheritance-based design is used instead of roles. A role, such as a Student role of a Person describes a characteristic associated with the object that exists because the object happens to participate in some relationship with another object; for example, the person in the student role has an "enrolled" relationship with a Course object. Some object-oriented design methods do not distinguish this use of roles from more stable aspects of objects. Thus there is a tendency to use inheritance to model roles; a Student role of a Person would be modeled as a subclass of a Person. However, neither the inheritance hierarchy nor the types of the objects can change with time.

Therefore, modeling roles as subclasses can cause roles to be fixed on creation; a Person cannot easily change his role from Student to Employee when circumstances change. From a modeling point of view, such restrictions are often not desirable, because this causes artificial restrictions on future extensibility of the object system, making future changes harder to implement because existing design needs to be updated.

Inheritance is often better used with a generalization mindset, such that common aspects of instantiable classes are factored to superclasses, for example, having a common superclass 'LegalEntity' for both Person and Company classes for all the common aspects of both. The distinction between role based design and inheritance based design can be made based on the stability of the aspect. Role based design should be used when it is conceivable that the same object participates in different roles at different times, and inheritance based design should be used when the common aspects of multiple classes are factored as superclasses, and do not change with time.

One consequence of separation of roles and superclasses is that this cleanly separates compile-time and run-time aspects of the object system. Inheritance is then clearly a compile-time construct. It does influence the structure of many objects at run-time, but the different kinds of structure that can be used are already fixed at compile-time.

To model the example of Person as an employee with this method, the modeling ensures that a Person class can only contain operations or data that are common to every Person instance regardless of where they are used. This would prevent use of a Job member in a Person class, because every person does not have a job, or at least it is not known that the Person class is only used to model Person instances that have a job. Instead, object-oriented design would consider some subset of all person objects to be in an "employee" role. The job information would be associated only with objects that have the employee role. Object-oriented design would also model the "job" as a role, since a job can be restricted in time, and therefore is not a stable basis for modeling a class. The corresponding stable concept is either "WorkPlace" or just "Work" depending on which concept is meant. Thus, from an object-oriented design point of view, there would be a "Person" class and a "WorkPlace" class, which are related by a many-to-many associatation "works-in", such that an instance of a Person is in employee role, when he works-in a job, where a job is a role of his work place in the situation when the employee works in it.

Note that in this approach, all of the classes that are produced by this design process form part of the same domain, that is, they describe things clearly using just one terminology. This is often not true for other approaches.

The difference between roles and classes is unclear if one assumes referential transparency because roles are types of references and classes are types of the referred-to objects.

Inheritance Program:-

 class Cat{
   public int x = 10;
   public int y = 20;

   public void show(){
     System.out.println(x+” ”+y);
   }
 }

 public class Rat extends Cat{
    public int z = 30;

    public static void main(String[]args){
       Rat r = new Rat();
       r.show();
       System.out.println(r.x+” ”+r.y+” ”+r.z);
   }
 }

In the above code, Rat class extends Cat class, so Rat class become child class of Cat class.