A long terme, l’héritage réduit le temps et les coûts de maintenance

d’un programme dans un autre ou utilisent les directives du compilateur (/COPY, par exemple) pour copier automatiquement le code source au moment de la compilation. Toutefois, quand les programmeurs coupent et collent du code source, il n’est pas certain que les modifications apportées à  une version du code se répercuteront sur les autres versions. Par conséquent, il faut déboguer et tester chaque programme séparément. De même, les directives /COPY ne peuvent pas garantir que les modifications apportées à  un module copy se répercuteront dans tous les programmes utilisant le module.
Avec l’héritage, la classe enfant utilise directement le code de la classe parent. Quand une classe Java prolonge une autre classe Java, elle peut utiliser les méthodes et variables définies par la classe parent ; si cette dernière est modifiée, la classe enfant utilise automatiquement le nouveau code. On ne risque donc pas d’avoir des versions incompatibles pour une même méthode. L’héritage présente toutefois un inconvénient : une modification de code risque de créer des problèmes dans d’autres parties de l’application qui fonctionnaient correctement auparavant. C’est certes un inconvénient susceptible de créer des problèmes de débogage mais, à  long terme, l’héritage réduit le temps et les coûts de maintenance parce que chaque segment de code n’est débogué et testé qu’une seule fois. A condition que tous les programmeurs respectent les règles d’encapsulation et que les signatures de méthodes restent inchangées, une modification de code dans une classe parent ne devrait pas créer de problèmes dans ses classes enfants.
L’héritage est fondé sur le comportement des objets dans le monde réel, c’est un élément essentiel pour la bonne compréhension du concept OO. La description classique de l’héritage requiert une relation de type « is a » (est un ou une) entre classes. Par exemple, un épagneul est un chien, est un mammifère, est un animal. En étendant cette idée aux objets de gestion, une police d’assurance auto personnelle est une police d’assurance de véhicule, est une police d’assurance de biens, est une police d’assurance.
Un programmeur Java peut définir des variables comme un numéro de police et un détenteur de police, communes à  toutes les polices d’assurance. Les méthodes qui sont les mêmes pour toutes les polices d’assurance, comme les ayants droit peuvent aussi être incluses dans la classe parente, Police dans cet exemple. D’autres variables et méthodes, comme le « nombre d’air bags à  l’avant » et « ajouter un conducteur supplémentaire » sont uniques aux polices d’assurance automobile. Enfin, des méthodes comme « calculer la prime » ou « payer l’indemnité » existent pour toutes les polices, mais chaque type de police applique ses méthodes différemment. Une méthode qui exécute la même fonction mais est appliquée différemment dans différentes classes illustre le concept de polymorphisme. Si on examine un exemple concret d’héritage, on rencontre tout naturellement l’idée de polymorphisme.