CSC/ECE 517 Fall 2011/ch6 6b mm: Difference between revisions
No edit summary |
No edit summary |
||
| Line 9: | Line 9: | ||
===Polymorphism=== | ===Polymorphism=== | ||
Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref> This is a great advantage since storing a subtype into that variable would | Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would | ||
===Code Reuse=== | ===Code Reuse=== | ||
Revision as of 06:19, 15 November 2011
Subclassing
Introduction
Subclassing, or inheritance, in object-oriented programming grants the programmer the ability to extend and refine the functionality of existing classes. This principle has many advantages that can make the programmers life much more simple. Principles and techniques have been defined that support and oppose the use of subclassing, making for a great debate. Here, some of these principles will be discussed to help determine when it is a good idea to utilize subclassing in a program.
Reasons for Subclassing
Polymorphism
Polymorphism is basically the utilization of a superclass type for a variable to hold a reference to an object whose class can be the supertype or any of its subtypes.<ref>Venners 1998</ref> This is a great advantage since storing a subtype into that variable would
Code Reuse
A great reason for subclassing is code reuse. When a superclass is extended, the subclass inherits all of the methods and properties of the superclass. This can be very useful to keep code duplication to a minimum.
There can be a drawback to this however. If only a portion of the code in a class is needed, then extending it could grant the subclass a lot of functionality that is not needed. This causes subclasses to be bulkier than they need to be.
Subclassing Principles
Liskov Substitution Principle
Probably the most well-known subclassing principle is the Liskov Substitution Principle (LSP). It states:
If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T) without altering any of the desirable properties of that program (correctness, task performed, etc.).<ref>Wikipedia - LSP</ref>
In other words, superclasses should be replaceable by their subclasses without altering the system in any way. This principle borrows ideas from the design by contract methodology by imposing restrictions on the conditions for which the methods of a class will function. It also restricts how subclass methods can be designed in terms of their return types (covariance) and method arguments (contravariance). These restrictions provide a very good ruleset to determine whether subclassing should be utilized or not.
References
Liskov Substitution Principle. Wikipedia
Citation Notes
<references/>
Full References
Venners, Bill. "Inheritance versus composition: Which one should you choose?" http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html. 1998