CSC/ECE 517 Fall 2011/ch17 5b uo: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
Line 21: Line 21:
== Representing "Is-a" Relationship ==
== Representing "Is-a" Relationship ==
A "Is-a" relationship can be represented by inheritance in most cases.
A "Is-a" relationship can be represented by inheritance in most cases.
For example cat "Is-a" animal. Lets consider a real world scenario of a university where a person can either be a student, an employee or both. So a student "Is-a" person. Can this "Is-a" relationship be represented by inheritance? Let us assume that a student can be represented as a subclass of person. What happens when the student graduates and join as an employee? Or if a person is both employee and a student? In case one when a student graduates and join as a employee all the references of student has to be removed which can be cumbersome. In case two same person can be an instance of employee as well as student which is confusing. Hence in this case the student "Is-a" person relation cannot be represented by inheritance. So how do we represent this relationship?
public class Person
{
private String name;
private String address;
public String getAddress() { return address; }
...other methods and data...
}


== Code Reuse ==
== Code Reuse ==

Revision as of 19:44, 30 October 2011

When to use Inheritance

Introduction

Inheritance is a useful programming concept, but it is easy to abuse this concept. Often interfaces or delegation are better options. In this wiki chapter, we will discuss the situations when to use and when not to use inheritance.

Inheritance is a good choice when:

Your inheritance hierarchy represents an "is-a" relationship and not a "has-a" relationship.

You can reuse code from the base classes.

You want to implement polymorphism.

The class hierarchy is reasonably shallow, and other developers are not likely to add many more levels.

You want to make global changes to derived classes by changing a base class.

These points are discussed in detail below

Representing "Is-a" Relationship

A "Is-a" relationship can be represented by inheritance in most cases. For example cat "Is-a" animal. Lets consider a real world scenario of a university where a person can either be a student, an employee or both. So a student "Is-a" person. Can this "Is-a" relationship be represented by inheritance? Let us assume that a student can be represented as a subclass of person. What happens when the student graduates and join as an employee? Or if a person is both employee and a student? In case one when a student graduates and join as a employee all the references of student has to be removed which can be cumbersome. In case two same person can be an instance of employee as well as student which is confusing. Hence in this case the student "Is-a" person relation cannot be represented by inheritance. So how do we represent this relationship?

public class Person { private String name; private String address; public String getAddress() { return address; } ...other methods and data... }

Code Reuse

Third level title if any

code here if any

Third Level Heading 2

  Add Code here

Inheritance-based Polymorphism

Shallow Class Hierarchies

Global Changes to Derived Classes Through the Base Class

Composition vs Inheritance

Drawbacks of inheritance

Inheritance is not without its own set of drawbacks. If inheritance is applied without due consideration problems can arise. In some situations it can:

  • Reduce the comprehensibility of code.
  • Make maintenance harder.
  • Make further development harder.
  • Reduce reliability of code.
  • Reduce overall reuse.

Conclusion

<EDIT THIS> We have considered the benefits and drawbacks of inheritance within an object oriented programming language. We have challenged the general perception that inheritance is by its very nature always good and have considered when it should and should not be used. We have re-assessed compositional reuse and made the case that it is as important, in an object oriented language, as inheritance in order to achieve the maximum possible reuse. We can therefore provide a summary of our findings that can be used as a set of guiding principles for object oriented development: · Avoid code dependency except on published protocol. · For structural inheritance direct extension is fine.

References