Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-07T14:29:41Z

Ttbrown4: /* Polymorphism */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software assets appropriately
#* Package names should be a category classification that encapsulating all the data
#* Interface names should be an unifying theme that groups classes together
#* Class names should be proper nouns
#* Method names should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

The items listed above are not a comprehensive guideline for the proper implementation of inheritance through code reuse.They are merely provided as a starting point for a programmer to consider during the preliminary states of software development. Any although inheritance provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application. For instance the below example displays the guideline presented in the above list.

<pre>

// The following code is used at a small organization to determine what the
// shipping cost of their packages are.
// This code demonstrates how inheritance can be used effectively to expand the
// functionality of a given program.
// Also observe the how the above guideline are followed.

class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java: The Complete Reference</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new Rectangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
// Even a class as simple as this one has problems. Consider what happens when a user leverages
// inheritance and uses theArrayList's clear() method to pop everything off the stack:

class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Scildt, herbert. ''Java: The Complete Reference,'' McGraw Hill, 2007.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library
*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-07T14:28:46Z

Ttbrown4: /* Costs of Using Inheritance */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software assets appropriately
#* Package names should be a category classification that encapsulating all the data
#* Interface names should be an unifying theme that groups classes together
#* Class names should be proper nouns
#* Method names should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

The items listed above are not a comprehensive guideline for the proper implementation of inheritance through code reuse.They are merely provided as a starting point for a programmer to consider during the preliminary states of software development. Any although inheritance provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application. For instance the below example displays the guideline presented in the above list.

<pre>

// The following code is used at a small organization to determine what the
// shipping cost of their packages are.
// This code demonstrates how inheritance can be used effectively to expand the
// functionality of a given program.
// Also observe the how the above guideline are followed.

class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java: The Complete Reference</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
// Even a class as simple as this one has problems. Consider what happens when a user leverages
// inheritance and uses theArrayList's clear() method to pop everything off the stack:

class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Scildt, herbert. ''Java: The Complete Reference,'' McGraw Hill, 2007.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library
*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-07T14:22:09Z

Ttbrown4: /* Different Perspectives on Inheritance */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software assets appropriately
#* Package names should be a category classification that encapsulating all the data
#* Interface names should be an unifying theme that groups classes together
#* Class names should be proper nouns
#* Method names should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

The items listed above are not a comprehensive guideline for the proper implementation of inheritance through code reuse.They are merely provided as a starting point for a programmer to consider during the preliminary states of software development. Any although inheritance provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application. For instance the below example displays the guideline presented in the above list.

<pre>

// The following code is used at a small organization to determine what the
// shipping cost of their packages are.
// This code demonstrates how inheritance can be used effectively to expand the
// functionality of a given program.
// Also observe the how the above guideline are followed.

class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java: The Complete Reference</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Scildt, herbert. ''Java: The Complete Reference,'' McGraw Hill, 2007.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library
*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:54:55Z

Ttbrown4: /* Additional Resources */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java: The Complete Reference</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Scildt, herbert. ''Java: The Complete Reference,'' McGraw Hill, 2007.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library
*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:54:28Z

Ttbrown4: /* Full Reference Information */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java: The Complete Reference</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Scildt, herbert. ''Java: The Complete Reference,'' McGraw Hill, 2007.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:54:07Z

Ttbrown4: /* Full Reference Information */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java: The Complete Reference</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Scildt, herbert. ''Java: The Complete Reference,'' McGraw Hill, 2007.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:50:07Z

Ttbrown4: /* Polymorphism */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java: The Complete Reference</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:48:16Z

Ttbrown4: /* Code Reuse */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. el al, 2005 </ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:46:58Z

Ttbrown4: /* Full Reference Information */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:46:03Z

Ttbrown4: /* Full Reference Information */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — Proper Inheritance and Substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:45:24Z

Ttbrown4: /* Full Reference Information */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — proper inheritance and substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

Software Engineering Observations. http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:44:37Z

Ttbrown4: /* Polymorphism */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref>Software Engineering Observations </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — proper inheritance and substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:43:30Z

Ttbrown4: /* Inheritance vs Delegation */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — proper inheritance and substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:37:40Z

Ttbrown4: /* IS-A */

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]<ref> Liskov's Substitution Principle </ref>. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation <ref> http://javaboutique.internet.com/tutorials/JavaOO/</ref> have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — proper inheritance and substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-04T02:35:51Z

Ttbrown4:

=When to use Inheritance: Lecture 17=
__TOC__

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.
'''
== Different Perspectives on Inheritance ==
In this article we will consider different perspectives on when to use inheritance and when not to use inheritance. Let us look at the following reasons that are considered when using inheritance:
'''

===Code Reuse===
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process: <ref> Tips for Effective Software Reuse </ref>

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

=== IS-A ===
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a<ref> When to Use Inheritance </ref>
" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes<ref>
Inheritance - Proper Inheritance and Substitutability</ref>
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

=== Public Interfaces ===

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=== Polymorphism ===

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation <ref> http://javaboutique.internet.com/tutorials/JavaOO/</ref> have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion==
Just having a similar interface is not sufficient for subclass/superclass or class/interface relationship; consistent behavior is also required. In particular, a sub class should not modify the behavior of the super class.Consider the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle] <ref> Liskov's Substitution Principle </ref>to make a class B a subclass of class A or to make an implementer of interface A.
If class B models a role played by class A, especially a temporary role, then B should not be a subclass of A. Instead referencing should be used.
Inheritance between a superclass A and a subclass B is appropriate if it promotes code reuse,each object of the sub class “is an” object of the super class, and the public interface of class B includes the interface of class A and the behavior of the methods in this interface in both classes is similar in both classes.
Inheritance, especially a deep inheritance tree is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it hard to code and to follow the flow of execution.If you have a class with behavior that applies to only some of the objects of the class, then con-
sider splitting the class into two classes associated by inheritance either directly or through a common abstract class or interface. When designing a class B that will be very similar to an existing class A, use referencing if you want the functionality of A but not the interface,and use inheritance only when you want the functionality and interface of A.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Tips for Effective Software Reuse. http://www.infoq.com/articles/vijay-narayanan-software-reuse, Oct. 2011.

When to Use Inheritance. http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx, Oct 2011.

Inheritance — proper inheritance and substitutability. http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#, Oct 2011.

Liskovs Substitution. Principle http://javaboutique.internet.com/tutorials/JavaOO, Oct 2011.

==Additional Resources==

Ruby, Sam, Dave Thomas and David Hansson. Agile Web Development with Rails: Third Edition: The Pragmatic Programmers LLC, 2009

*http://en.wikipedia.org/wiki/Don't_Repeat_Yourself
*http://en.wikipedia.org/wiki/Software_library

*http://stackoverflow.com/questions/4348557/liskovs-substitution-principle-how-to-model-square-and-rectangle
*http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html
*http://www.dlugosz.com/Perl6/web/isa-inheritance.html
*http://inheritingjava.blogspot.com/2011/01/chapter-14-coupling-and-cohesion.html
*http://www.builderau.com.au/program/java/soa/Dynamic-Classification-with-Interfaces-and-Delegation/0,339024620,320269511,00.htm
*http://www.objectmentor.com/resources/articles/lsp.pdf
*http://home.cogeco.ca/~ve3ll/jatutor5.htm

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T03:37:55Z

Ttbrown4:

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> Tips for Effective Software Reuse
http://www.infoq.com/articles/vijay-narayanan-software-reuse </ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation <ref> http://javaboutique.internet.com/tutorials/JavaOO/</ref>==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T03:25:18Z

Ttbrown4:

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation <ref> http://javaboutique.internet.com/tutorials/JavaOO/</ref>==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> Tips for Effective Software Reuse
http://www.infoq.com/articles/vijay-narayanan-software-reuse </ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:54:09Z

Ttbrown4: /* Inheritance vs Delegation */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> Tips for Effective Software Reuse
http://www.infoq.com/articles/vijay-narayanan-software-reuse </ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation <ref> http://javaboutique.internet.com/tutorials/JavaOO/</ref>==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:53:18Z

Ttbrown4: /* IS-A */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> Tips for Effective Software Reuse
http://www.infoq.com/articles/vijay-narayanan-software-reuse </ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the [http://javaboutique.internet.com/tutorials/JavaOO Liskov's Substitution Principle]. The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:50:17Z

Ttbrown4: /* Code Reuse */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> Tips for Effective Software Reuse
http://www.infoq.com/articles/vijay-narayanan-software-reuse </ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:49:09Z

Ttbrown4: /* Polymorphism */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> Java Reference Book</ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> Software Engineering Observations
http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm </ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:46:50Z

Ttbrown4: /* Conclusion: */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> </ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> 3</ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:43:08Z

Ttbrown4: /* Conclusion: */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> </ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> 3</ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

=References=

==Citation Notes==
<references/>

==Full Reference Information==

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:40:42Z

Ttbrown4: /* IS-A */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> </ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> 3</ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

# A car is a vehicle.
# A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:39:16Z

Ttbrown4: /* Polymorphism */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> </ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> 3</ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}

class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}
}
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:37:09Z

Ttbrown4: /* Polymorphism */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> </ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> 3</ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
</pre>
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:36:32Z

Ttbrown4: /* Polymorphism */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. <ref> </ref>This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler. In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. <ref> 3</ref> Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:32:31Z

Ttbrown4: /* Code Reuse */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> 2</ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

/*
Output
Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40
*/
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:31:33Z

Ttbrown4: /* Code Reuse */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process <ref> Tips for Effective Software Reuse
http://www.infoq.com/articles/vijay-narayanan-software-reuse
<\ref>.:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

/*
Output
Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40
*/
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:25:42Z

Ttbrown4: /* What is Inheritance? */

== What is Inheritance ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

/*
Output
Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40
*/
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T02:24:00Z

Ttbrown4: /* Code Reuse */

== What is Inheritance? ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.<ref>Frakes, W.B. and Kyo Kang, (2005), "Software Reuse Research: Status and Future", IEEE Transactions on Software Engineering, 31(7), July, pp. 529-536.</ref> A [http://en.wikipedia.org/wiki/Software_library software library] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself] design principle. And although inheritance provides this capability a few things should be considered during the design process:

# Focus on well-defined general aspects of the software program,
#* look for areas within the program where a library can be utilized or possibly developed for future reuse
# Name software asses appropriately
#* Package should an category classification encapsulating all the data
#* Interfaces should be unifying theme that group of classes
#* Classes should be proper nouns
#* Methods should be simple action verbs
# Being consistent is critical for reusing code over time
#* This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of an inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.

<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

/*
Output
Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40
*/
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T01:54:44Z

Ttbrown4:

== What is Inheritance? ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.[1] A software library [external link] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the DRY {link to DRY} design principle. And although inheritance provides this capability a few things should be considered during the design process:
1. Focus on well-defined general aspects of the software program,
a. look for areas within the program where a library can be utilized or possibly developed for future reuse
1. Name software asses appropriately, in example:
a. Package should an category classification encapsulating all the data
b. Interfaces should be unifying theme that group of classes
c. Classes should be proper nouns
d. Methods should be simple action verbs
1. Being consistent is critical for reusing code over time
a. This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.
<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

/*
Output
Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40
*/
</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T01:49:09Z

Ttbrown4: /* IS-A vs HAS-A */

== What is Inheritance? ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.[1] A software library [external link] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the DRY {link to DRY} design principle. And although inheritance provides this capability a few things should be considered during the design process:
1. Focus on well-defined general aspects of the software program,
a. look for areas within the program where a library can be utilized or possibly developed for future reuse
1. Name software asses appropriately, in example:
a. Package should an category classification encapsulating all the data
b. Interfaces should be unifying theme that group of classes
c. Classes should be proper nouns
d. Methods should be simple action verbs
1. Being consistent is critical for reusing code over time
a. This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.
<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40

</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T01:48:27Z

Ttbrown4:

== What is Inheritance? ==
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==IS-A vs HAS-A==

Perspectives of Inheritance

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.[1] A software library [external link] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the DRY {link to DRY} design principle. And although inheritance provides this capability a few things should be considered during the design process:
1. Focus on well-defined general aspects of the software program,
a. look for areas within the program where a library can be utilized or possibly developed for future reuse
1. Name software asses appropriately, in example:
a. Package should an category classification encapsulating all the data
b. Interfaces should be unifying theme that group of classes
c. Classes should be proper nouns
d. Methods should be simple action verbs
1. Being consistent is critical for reusing code over time
a. This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.
<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40

</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:

{| class="wikitable" border="1"

|-
! Scenarios
! Inheritance
! Delegation

|-
! Polymorphism
| If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A .
|If B is composed with A, then this subtype polymorphism does not apply to B.

|-
! Interface
| If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want
|if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.

|-
! Efficiency
| If B is a subclass, there is direct execution of any inherited methods.
| if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
|-
! Amount of Code
| If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A.
| If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
|-
! Dynamic Changeability
| If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods.
| If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

|}

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T01:29:09Z

Ttbrown4: /* Inheritance vs Delegation */

----------------------------------------------------------------------------------------------------------------------------
When to use inheritance

What is Inheritance?
Is-a vs Has-a

Perspectives of Inheritance
1. Code Reuse
2. Is-A
3. Public Interfaces
4. Polymorphism

Costs of Using Inheritance

== Inheritance vs Delegation ==
--------------------------------------------------------------------------------------------------------
What is Inheritance?
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

==IS-A vs HAS-A==

Perspectives of Inheritance

==Code Reuse==
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.[1] A software library [external link] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the DRY {link to DRY} design principle. And although inheritance provides this capability a few things should be considered during the design process:
1. Focus on well-defined general aspects of the software program,
a. look for areas within the program where a library can be utilized or possibly developed for future reuse
1. Name software asses appropriately, in example:
a. Package should an category classification encapsulating all the data
b. Interfaces should be unifying theme that group of classes
c. Classes should be proper nouns
d. Methods should be simple action verbs
1. Being consistent is critical for reusing code over time
a. This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.
<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>

== IS-A ==
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

== Public Interfaces ==

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

== Polymorphism ==

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40

</pre>

== Costs of Using Inheritance ==
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

== Inheritance vs Delegation ==
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:
Scenarios Inheritance Delegation
Polymorphism If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A . If B is composed with A, then this subtype polymorphism does not apply to B.
Interface If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.
Efficiency If B is a subclass, there is direct execution of any inherited methods. if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
Amount of Code If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A. If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
Dynamic Changeability If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods. If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T01:26:26Z

Ttbrown4:

----------------------------------------------------------------------------------------------------------------------------
When to use inheritance

What is Inheritance?
Is-a vs Has-a

Perspectives of Inheritance
1. Code Reuse
2. Is-A
3. Public Interfaces
4. Polymorphism

Costs of Using Inheritance

== Inheritance vs Delegation ==
--------------------------------------------------------------------------------------------------------
What is Inheritance?
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes or superclasses or parent classes or ancestor classes. The new classes are known as derived classes or subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

IS-A vs HAS-A

Perspectives of Inheritance
Code Reuse
A milestone on the pathway to an elegant implementation of inheritance is software reuse. Software reuse, better known as code reuse, is the practice of using existing software or software knowledge to build new software programs.[1] A software library [external link] is a practical example of code reuse. Whether it is a large corporation or a collegiate engineering project, programmers utilize existing code repositories to reduce time spent during the development phase. In a well-designed multi-tier software program where inheritance is properly implemented code reuse is achieved through using the DRY {link to DRY} design principle. And although inheritance provides this capability a few things should be considered during the design process:
1. Focus on well-defined general aspects of the software program,
a. look for areas within the program where a library can be utilized or possibly developed for future reuse
1. Name software asses appropriately, in example:
a. Package should an category classification encapsulating all the data
b. Interfaces should be unifying theme that group of classes
c. Classes should be proper nouns
d. Methods should be simple action verbs
1. Being consistent is critical for reusing code over time
a. This is most common with products that have a long life-span and continually evolve in functionality

By no means are the items listed above a comprehensive guideline for the proper implementation of inheritance through code reuse. It is merely provided as potential assets to programmer looking for a foundational starting point. Any although inherit ace provides the ability to reuse any code; the practically of that implementation is strictly dependent on the programmer and the requirements of the application.
<pre>
class Parcel_Dimension {
double width;
double height;
double depth;

// constructor when all dimension specified
Parcel (double w, double h, double d){
weight = w;
height = h;
depth = d;
}

}

class ParcelWeight extends Parcel_Dimension {
double weight; // weight of parcel

// constructor for parcel weight
ParcelWeight(double w, double h, double d, double m)
width = w;
height = h;
depth = d;
weight = m;
}

class Shipping_Cost extends ParcelWeight {
double cost;

// constructor for shiping price
Shipping_Cost(double w, double h, double d, double m, double c)

super(w, h, d, m);
cost c;
}

class Shipment_Printout{
public static void main(String args[]){
Shipment_cost letter1 = new Shipment_cost (10, 20, 15, 10, 3.66)

System.out.println(" Weight of letter is: " + letter1.weight);
System.out.println(" Shipping cost: " + letter1.cost);
}

</pre>
IS-A
Inheritance allows a new class to extend an existing class. The new class inherits the members of the class it extends. When one object is a specialized version of another object, there is an "is a" relationship between them. Here are a few examples of the "is a" relationship:

1. A car is a vehicle.
2. A rectangle is a shape.

When an "is a" relationship exists between objects, it means that the specialized object has all of the characteristics of the general object, plus additional characteristics that make it special. In object-oriented programming, inheritance is used to create an "is a" relationship among classes. This allows you to extend the capabilities of a class by creating another class that is a specialized version of it.

Consider the following implementation of the Circle and Ellipse classes
using inheritance. In the implementation Circle will be the sub-classclass of the Ellipse, hence it doesn’t need to implement anything but a constructor. From a geometrical perspective, every circle “is a” ellipse. Furthermore, there are certainly good opportunities for code reuse between them. Therefore, it seems natural to make the Circle class a subclass of the Ellipse class. But is this a good decision?

<pre>
public class Ellipse
{
private int x, y, width, height;
public Ellipse(int x, int y, int w, int h) {
this.x = x; this.y = y; width = w; height = h;
}
public int getWidth() { return width; }
public int getHeight() { return height; }
public void setSize(int w, int h) { width = w; height = h; }
}

public class Circle extends Ellipse
{
public Circle(int x, int y, int width) {
super(x, y, width, width);
}
}
</pre>
Because of the fact that subclasses inherit all methods of their superclasses, the Circle
class now inherits a setSize method that has two parameters. A call to this method
can make the width and height of the Circle unequal, a rather undesirable outcome.
A setSize method for Squares should just take one parameter.
This can be avoided by nullifying the negative effects of the inherited setSize method by overriding it in the subclass. For example, we might add the following method to the Circle class:
<pre>
public void setSize(int w, int h)
{
width = h;
height = h;
}
</pre>
thereby allowing users to modify the size of the circle.

Our problem here is that the subclass does not have behavior consistent with
the behavior of its superclass. Such consistent behavior is necessary for elegant
code. This thereby ensure the Principle of Least Astonishment.

Let us consider the inconsistent behavior between the Ellipse Class and the Circle class, with respect to the Liskov's Substitution Principle(LSP) .
The setSize method of the Ellipse class has the behavior of modifying the
width independently of the height. A setSize method of the Cirlce class can-
not have that behavior and still preserve squareness, and therefore the Circle class’
setSize method does not do everything that the Ellipse class’ setSize
method does. The conclusion is that Circle should not be a subclass of Ellipse.

Public Interfaces

If class S responds to all the messages that class C responds to, and then some, it seems appropriate for S to be a subclass of C. Let us consider the following case:
A video store application which has a Person class, with name, address fields. It also has a Staff class, which has name, address fields and a Customer Class which also name, address fields. A simple object oriented approach would be to say that a Customer "is a" Person also Staff “is a” Customer, therefore create classes as so.

<pre>
public class Person
{
private String name;
private String address;
public String getAddress()
{
return address;
}
…
}
public class
public class Customer extends Person
{
private String CustomerID;
...
}

public class Staff extends Person
{
private String StaffID;
...
}

</pre>
This system works fine until we have someone who is both a customer and a member of staff. Assuming that we don't really want our everyone list to have the same person in twice, once as a Customer and once as a Staff, we make an arbitrary choice between:
It would be overly complex and difficult to maintain if you attempt to have a set of derived classes that implement the People. This is especially true given that the above example is very simple - in most real applications, things will be more complex. In this case, we would go with different approach. I would implement the Person class and include in it a collection of "roles". Each person could have one or more roles such as "Customer" and "Staff”. This will make it easier to add roles as new requirements are discovered. For example, you may simply have a base "Role" class, and derive new roles from them. In this way, the Person object can be considered to exist permanently, but the person’s roles can come and go. Furthermore, there is no duplication of data.

Polymorphism

Polymorphism, Greek for “many forms” (put link to external definition) is a feature that allows one interface to be used for a general class of actions. Moreover, the concept of polymorphism is often expressed by the phrase, “one interface, multiple methods,” which means implies that a general interface should be associated with a group of related actives. {site from book}This in turn provides a situation that aids in the reduction of a programs complexity by allowing the same interface to be used throughout different situations The responsibility of knowing which method needs to be evoke is left up to the compiler.
Software Engineering Observations
In respect to inheritance polymorphism should be used when a programmer needs to deal in generalities and let the execution-time environment handle the specifics. [2] Proper use of polymorphism promotes extensibility, and software that invokes polymorphic behavior is independent of the object types to which messages are sent.
2http://faculty.inverhills.mnscu.edu/speng/cs1126/Notes/Polymorphism/What%20is%20Polymorphism.htm

<pre>
// Using run-time polymorphism
class Figure_2D{
double dim1;
double dim2;

Figure_2D(double a, double b){
dim1 = a;
dim2 = b;
}

double area(){
System.out.println("Area for Figure is undefined.");
return 0;
}
}
class Rectangle extends Figure_2D{
Rectangle (double a, double b){
super(a, b);
}
// overide area for rectangle
double area(){
System.out.println("Inside Area for Rectangle.");
return dim1*dim2;
}
}
class Triangle extends Figure_2D{
Triangle (double a, double b){
super(a, b);
}
// overide area for right triangle
double area(){
System.out.println("Inside Area for Triangle.");
return dim1*dim2/2;
}
}

class FindAreas{
public static void main (String args[]) {
Figure r new REctangel (9, 5);
Triangle t = new Triangle(10, 8);
Figure figref;

figref = r;
System.out.println("Area is" + figref.area());
figref = t;
System.out.println("Area is" + figref.area());
}

Inside Area for Rectangle.
Area is 45
Inside Area for Triangle.
Area is 40

</pre>

Costs of Using Inheritance
There are even more costs to be considered when using inheritance, in addition to those we’ve already addressed.

One problem with inheritance, especially a deep inheritance tree with many generations, is that the code for the methods of a class low in the tree is spread out among all its ancestors higher in the tree, which makes it harder for the reader of the code to follow the flow of execution. That is, suppose someone is reading code and sees that a method foo is invoked on an object. If the object’s class does not implement foo, then the reader needs to look to the object’s immediate superclass. If that class does not implement foo, then a further search up the inheritance hierarchy needs to be made. To complicate matters, foo may invoke another method bar on the same object. There need be little relationship between the locations of foo and bar in the inheritance tree, and so the reader again needs to start at the object’s class and search up the inheritance tree, to find the implementation of bar. Matters are even worse if the reader is not sure of the object’s class and knows, for example, only that the object could belong to any of the subclasses of a given class. In such cases, it is impossible to figure out exactly which method body of which class gets executed at any given time.

Another problem with inheritance is that all subclasses are very tightly tied with their superclasses. This coupling comes from the fact that, to guarantee certain behavior in a subclass, that subclass needs to know significant parts of the implementation of the methods of the superclasses.

Eg:
Let's examine the superclass and subclass coupling problems. The following Stack class extends Java's ArrayListclass to make it behave like a stack:

<pre>
class Stack extends ArrayList
{ private int stack_pointer = 0;
public void push( Object article )
{ add( stack_pointer++, article );
}
public Object pop()
{ return remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < articles.length; ++i )
push( articles[i] );
}
}

Even a class as simple as this one has problems. Consider what happens when a user leverages inheritance and uses theArrayList's clear() method to pop everything off the stack:
Stack a_stack = new Stack();
a_stack.push("1");
a_stack.push("2");
a_stack.clear();

</pre>
The code successfully compiles, but since the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state. The next call to push() puts the new item at index 2 (the stack_pointer's current value), so the stack effectively has three elements on it—the bottom two are garbage. (Java's Stackclass has exactly this problem; don't use it.)

Inheritance vs Delegation
Delegation is an alternative to inheritance for reusing code among multiple classes. Inheritance uses the IS‐A relationship for re‐use; delegation uses the HAS‐A reference relationship to do the same. Inheritance and delegation have the same kind of relationship that, both are alternatives for fixing a problem, with one more appropriate than the other in some situations. In this chapter, we will study the nature of delegation, see how we can convert an inheriting class to a delegating one, compare the advantages and disadvantages of the two approaches, and identify scenarios in which they should be used.

The main reason, as mentioned, before, for using inheritance is sharing of code among multiple classes. However, as shown in the figure, while inheritance implies code reusability, code reusability does not require inheritance. Delegation is an alternative approach to allow multiple classes to share code. In the case of inheritance, a reusing class has an IS‐A relationship with a reused class. Thus, it inherits code from the reused class. In the case of delegation, the reused class HAS‐A reference to the reused class.
This reference allows it to delegate tasks to the reused class.
We shall consider the same case of the Stack class extending the Java's ArrayListclass to make it behave like a stack. As discussed before, the problem is that the base class doesn't know anything about the stack pointer, the Stack object is now in an undefined state.
One solution to the undesirable method-inheritance problem is for Stack to override all ArrayList methods that can modify the array's state, so the overrides either manipulate the stack pointer correctly or throw an exception.

This approach has two disadvantages. First, if you override everything, the base class should really be an interface, not a class. There's no point in implementation inheritance if you don't use any of the inherited methods. Second, and more importantly, you don't want a stack to support all ArrayList methods. That pesky removeRange() method isn't useful, for example. The only reasonable way to implement a useless method is to have it throw an exception, since it should never be called. This approach effectively moves what would be a compile-time error into run-time.

A better solution to the base-class issue is encapsulating the data structure instead of using inheritance. Here's a new-and-improved version of Stack:

<pre>
class Stack
{
private int stack_pointer = 0;
private ArrayList the_data = new ArrayList();
public void push( Object article )
{ the_data.add( stack_pointer++, article );
}
public Object pop()
{ return the_data.remove( --stack_pointer );
}
public void push_many( Object[] articles )
{ for( int i = 0; i < o.length; ++i )
push( articles[i] );
}
}
</pre>

Let us consider different scenarios under which inheritance and delegation fares each other:
Scenarios Inheritance Delegation
Polymorphism If B is a subclass of A, then subtype polymorphism is possible and so an object of class B can be used anywhere an object of class A . If B is composed with A, then this subtype polymorphism does not apply to B.
Interface If B is a subclass of A, then B inherits all methods of A, and so the interface of B must include all the methods in the interface of A, whether B wants them all or not. Furthermore, it is usually not appropriate to “void out” or nullify the methods of A that B doesn’t want if B is composed with A, then the public interface of B need not be related at all to the public interface of A, and so you have the flexibility to design B exactly the way you want.
Efficiency If B is a subclass, there is direct execution of any inherited methods. if B forwards requests to A, then the methods of B must call methods of A, which results in slightly higher overhead costs.
Amount of Code If B is a subclass of A, you need to implement in B only the methods of B that aren’t already inherited from A. If B forwards requests to A, then you must implement all of B’s methods yourself. Although many of these methods might merely call a corresponding method in A, there is still more code to write and therefore more chance of errors.
Dynamic Changeability If B is a subclass of A, then at run-time, there is no way to change the behavior of the inherited methods. If B forwards requests to A, then at run-time, B can change the object of class A or a subclass of A to which it forwards requests.

==Conclusion:==

References:

http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6](Circle and Ellipse)

http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx (Is-A relationship)

http://pages.cs.wisc.edu/~cs368-1/JavaTutorial/NOTES/Inheritance-intro.html(Inheritance)

http://javaboutique.internet.com/tutorials/JavaOO/(LSP)

http://www.javaworld.com/javaworld/jw-11-1998/jw-11-techniques.html?page=1(Inheritance vs Delegation)

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-02T18:07:37Z

Ttbrown4: Created page with "test 1"

test 1

CSC/ECE 517 Fall 2011

2011-11-02T18:07:19Z

Ttbrown4:

[[Link title]]
*[[CSC/ECE 517 Fall 2011/ch1 1a ms]]

*[[CSC/ECE 517 Fall 2011/ch1 1a cs]]

*[[CSC/ECE 517 Fall 2011/ch1 1a ri]]

*[[CSC/ECE 517 Fall 2011/ch1 1a lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1b sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1b ds]]

*[[CSC/ECE 517 Fall 2011/ch1 1b tj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c cm]]

*[[CSC/ECE 517 Fall 2011/ch1 1c sj]]

*[[CSC/ECE 517 Fall 2011/ch1 1c ka]]

*[[CSC/ECE 517 Fall 2011/ch1 1d sr]]

*[[CSC/ECE 517 Fall 2011/ch1 1e vs]]

*[[CSC/ECE 517 Fall 2011/ch1 1e aa]]

*[[CSC/ECE 517 Fall 2011/ch1 1a sc]]

*[[CSC/ECE 517 Fall 2011/ch1 1e dm]]

*[[CSC/ECE 517 Fall 2011/ch1 1e an]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sa]]

*[[CSC/ECE 517 Fall 2011/ch1 1e lm]]

*[[CSC/ECE 517 Fall 2011/ch1 1g vn]]

*[[CSC/ECE 517 Fall 2011/ch1 1f rs]]

*[[CSC/ECE 517 Fall 2011/ch1 1f sv]]

*[[CSC/ECE 517 Fall 2011/ch1 1g jn]]

*[[CSC/ECE 517 Fall 2011/ch1 1h ps]]

*[[CSC/ECE 517 Fall 2011/ch1 1e sm]]

*[[CSC/ECE 517 Fall 2011/ch1 1i zf]]

*[[CSC/ECE 517 Fall 2011/ch1 1g rn]]

*[[CSC/ECE 517 Fall 2011/ch1 1i cl]]

*[[CSC/ECE 517 Fall 2011/ch1 1d ss]]

*[[CSC/ECE 517 Fall 2011/ch1 1i lj]]

*[[CSC/ECE 517 Fall 2011/ch1 1h hs]]

*[[CSC/ECE 517 Fall 2011/ch1 1d gs]]

*[[CSC/ECE 517 Fall 2011/ch1 2b ns]]

*[[CSC/ECE 517 Fall 2011/ch1 2b jp]]

*[[CSC/ECE 517 Fall 2011/ch1 2a av]]

*[[CSC/ECE 517 Fall 2011/ch2 2f jm]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ad]]

*[[CSC/ECE 517 Fall 2011/ch2 2e kt]]

*[[CSC/ECE 517 Fall 2011/ch2 2e gp]]

*[[CSC/ECE 517 Fall 2011/ch1 2b qu]]

*[[CSC/ECE 517 Fall 2011/ch2 2c bs]]

*[[CSC/ECE 517 Fall 2011/ch1 2c rs]]

*[[CSC/ECE 517 Fall 2011/ch1 2a ca]]

*[[CSC/ECE 517 Fall 2011/ch1 2b rv]]

*[[CSC/ECE 517 Fall 2011/ch2 2c ds]]

*[[CSC/ECE 517 Fall 2011/ch2 2b sa]]

*[[CSC/ECE 517 Fall 2011/ch2 2f vh]]

*[[CSC/ECE 517 Fall 2011/ch2 2e ps]]

*[[CSC/ECE 517 Fall 2011/ch3 3a oe]]

*[[CSC/ECE 517 Fall 2011/ch3 3h rr]]

*[[CSC/ECE 517 Fall 2011/ch3 3h ss]]

*[[CSC/ECE 517 Fall 2011/ch3 4b js]]

*[[CSC/ECE 517 Fall 2011/ch3 4b ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4b ds]]

*[[CSC/ECE 517 Fall 2011/ch4 4i aa]]

*[[CSC/ECE 517 Fall 2011/ch4 4i sd]]

*[[CSC/ECE 517 Fall 2011/ch4 4d mt]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ls]]

*[[CSC/ECE 517 Fall 2011/ch4 4d ch]]

*[[CSC/ECE 517 Fall 2011/ch4 4c ap]]

*[[CSC/ECE 517 Fall 2011/ch4 4h sv]]

*[[CSC/ECE 517 Fall 2011/ch4 4e cl]]

*[[CSC/ECE 517 Fall 2011/ch4 4e gs]]

*[[CSC/ECE 517 Fall 2011/ch4 4a ga]]

*[[CSC/ECE 517 Fall 2011/ch4 4f sl]]

*[[CSC/ECE 517 Fall 2011/ch4 4i js]]

*[[CSC/ECE 517 Fall 2011/ch4 4f ss]]

*[[CSC/ECE 517 Fall 2011/ch4 4c dm]]

*[[CSC/ECE 517 Fall 2011/ch4 4g as]]

*[[CSC/ECE 517 Fall 2011/ch4 4g nv]]

*[[CSC/ECE 517 Fall 2011/ch4 4g ms]]

*[[CSC/ECE 517 Fall 2011/ch4 4h kp]]

*[[CSC/ECE 517 Fall 2011/ch4 4h as]]

*[[CSC/ECE 517 Fall 2011/ch4 4j fw]]

*[[CSC/ECE 517 Fall 2011/ch4 4f rs]]

*[[CSC/ECE 517 Fall 2011/ch4 4i lc]]

*[[CSC/ECE 517 Fall 2011/ch17 5b uo]]

*[[CSC/ECE 517 Fall 2011/ch17 5b br]]

*[[CSC/ECE 517 Fall 2011/ch5 5d he]]

*[[trial]]

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T20:18:47Z

Ttbrown4: /* Full Reference Information */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called [http://en.wikipedia.org/wiki/Basecamp_(software) Basecamp] developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project<ref>Rails Core Team Profiles</ref>. Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines<ref>Ruby on Rails 2.3 Release Notes</ref>. Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with [http://en.wikipedia.org/wiki/Merb Merb] and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==
[http://rubyonrails.org/core "The Core Team"]. Riding Rails. Retrieved September 2011.

[http://guides.rubyonrails.org/2_3_release_notes.html Rails Ruby on Rails 2.3 Release Notes"]. Riding Rails. Retrieved September 2011.

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

== External Links ==
* [http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/ Rails 1.0: Party like it's one oh oh!]
* [http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done Rails 2.0: It's done!]
* [http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more Rails 2.3: Templates, Engines, Rack, Metal, much more!]
* [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done Rails 3.0: It's Ready]

* [http://guides.rubyonrails.org/2_3_release_notes.html Rails Ruby on Rails 2.3 Release Notes]
* [http://guides.rubyonrails.org/3_0_release_notes.html Rails Ruby on Rails 3.0 Release Notes]

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T20:16:00Z

Ttbrown4:

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called [http://en.wikipedia.org/wiki/Basecamp_(software) Basecamp] developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project<ref>Rails Core Team Profiles</ref>. Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines<ref>Ruby on Rails 2.3 Release Notes</ref>. Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with [http://en.wikipedia.org/wiki/Merb Merb] and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==
[http://rubyonrails.org/core "The Core Team"]. Riding Rails. Retrieved September 2011.

[http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more "Rails 2.3: Templates, Engines, Rack, Metal, much more!"]. Riding Rails. Retrieved September 2011.

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

== External Links ==
* [http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/ Rails 1.0: Party like it's one oh oh!]
* [http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done Rails 2.0: It's done!]
* [http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more Rails 2.3: Templates, Engines, Rack, Metal, much more!]
* [http://weblog.rubyonrails.org/2010/8/29/rails-3-0-it-s-done Rails 3.0: It's Ready]

* [http://guides.rubyonrails.org/2_3_release_notes.html Rails Ruby on Rails 2.3 Release Notes]
* [http://guides.rubyonrails.org/3_0_release_notes.html Rails Ruby on Rails 3.0 Release Notes]

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:53:44Z

Ttbrown4:

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called [http://en.wikipedia.org/wiki/Basecamp_(software) Basecamp] developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project<ref>Rails Core Team Profiles</ref>. Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==
"The Core Team". Riding Rails. Retrieved September 2011.http://rubyonrails.org/core

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:48:56Z

Ttbrown4: /* Full Reference Information */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called [http://en.wikipedia.org/wiki/Basecamp_(software) Basecamp] developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project<ref>Rails Core Team </ref>. Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available <ref>Rails 1.0 </ref>. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==
"The Core Team". Riding Rails. Retrieved September 2011.http://rubyonrails.org/core

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:47:01Z

Ttbrown4: /* Introduction */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called [http://en.wikipedia.org/wiki/Basecamp_(software) Basecamp] developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project<ref>Rails Core Team </ref>. Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available <ref>Rails 1.0 </ref>. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011." http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:44:53Z

Ttbrown4: /* Introduction */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called [http://en.wikipedia.org/wiki/Basecamp_(software) Basecamp] developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available <ref>Rails 1.0 </ref>. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011." http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:42:39Z

Ttbrown4: /* Introduction */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available <ref>Rails 1.0 </ref>. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011." http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:41:51Z

Ttbrown4: /* Introduction */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of [http://en.wikipedia.org/wiki/Convention_over_Configuration Configuration over Convention] and [http://en.wikipedia.org/wiki/Don't_Repeat_Yourself Don't Repeat Yourself].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available <ref>Rails 1.0 </ref>. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011." http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:39:30Z

Ttbrown4: /* Rails 1.0 */

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available <ref>Rails 1.0 </ref>. This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011." http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T19:36:23Z

Ttbrown4:

=Introduction=
The original Ruby on Rails platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

As you can see a lot changed since the first release of Rails. We will explore a few of the key areas that changed between Rails 2 and Rails 3 that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

"Rails 1.0: Party like it's one oh oh!". Riding Rails. Retrieved September 2011." http://weblog.rubyonrails.org/2005/12/13/rails-1-0-party-like-its-one-oh-oh/

"Rails 2.0: It's done!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2007/12/7/rails-2-0-it-s-done

"Rails 2.3: Templates, Engines, Rack, Metal, much more!". Riding Rails. Retrieved September 2011. http://weblog.rubyonrails.org/2009/3/16/rails-2-3-templates-engines-rack-metal-much-more

"Rails Ruby on Rails 2.3 Release Notes" Riding Rails. Retrieved September 2011. http://guides.rubyonrails.org/2_3_release_notes.html

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T18:12:09Z

Ttbrown4: /* Rails 3.0 */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===
Between Rails 2.3 and the release of Rails 3.0, Rails announced that it would merge with Merb and that Rails 3.0 would be the successor to both Rails 2 and Merb. Merb which is short for Mongrel+Erb, key feature that prompted the join Rails was its component modularity, extensible API design, and vertical scalability.

=Rails 2 vs. Rails 3=

A lot changed in the update from Rails 2 to Rails 3. We will explore a few of the key areas that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.

CSC/ECE 517 Fall 2011/ch2 2f mm

2011-09-22T18:11:55Z

Ttbrown4: /* Rails 2.3 */

=Introduction=
The original Ruby on Rail platform was extracted from the web-based project-management tool called Basecamp developed by 37signals. Ruby on Rails’ creator, David Heinemeier Hansson, began work on the Rails in early 2003 and released it as open source code in 2004, but it wasn’t until 2005 that Hansson shared commit rights to the project. [REFERENCE] Hansson designed Ruby on Rails to be an out of the box development framework that includes everything a programmer needs to create database-driven web applications according to the Model-View-Control pattern of separation. Ruby on Rails is based on the two key paradigms of Convention over Configuration [WIKI LINK] and Don’t Repeat Yourself (DRY) [WIKI LINK].

=History of Rails Development=
Throughout the development of the Rails framework there have been four significant releases alongside of the usual patches, fixes, and upgrades.

===Rails 1.0===
Initially, Rails 1.0 was released 15 months after the original source was made available. [REFERENCE] This version contained the structural foundation of what would become a powerful open source motivator for the Ruby platform. Though there were patches and code adjustments in Rails 1.2 the next major release was Rails 2.0.

===Rails 2.0 ===
Rails 2.0 was a major facelift for the framework and much of the effort went into improving the resources and polishing the overall package by making it more lean. Among some of these improvements was a focus on increasing security by adding a new module to work with HTTP Basic Authentication and providing a built-in mechanism for dealing with CRSF attacks. Other improvements were in the areas of changing certain syntactical nomenclature as well as simplifying the format for a few templates.

===Rails 2.3===
The next major update was Rails 2.3 at it was the most structural update prior to Rails 3.0 being released. The two primary changes in the architecture of the Rails application was the complete integration of the Rack modular web server interface and a renewed support for Rails Engines. {link 2} Alongside of these changes were updates to templates, the addition of built-in support for HTTP Digest Authentication, nested forms models, Metal, and improved caching performance among other things.

===Rails 3.0===

=Rails 2 vs. Rails 3=

A lot changed in the update from Rails 2 to Rails 3. We will explore a few of the key areas that will affect a developer's everyday coding.

==Rails Application Scripts==

When you create a new Rails application, a directory named <tt>script</tt> is generated. In Rails 2, this directory is populated with a set of scripts that can be executed by the programmer. A few of the more important ones are as follows<ref>Ruby 2009, pp 257-258 </ref>:
*<tt>generate</tt>: Used to generate code for controllers, mailers, models, scaffolds and other sets of code.
*<tt>destroy</tt>: Used to destroy code created by the <tt>generate</tt> method.
*<tt>server</tt>: Starts up the Rails application in a self-contained web server.
*<tt>plugin</tt>: Helps with the installation and administration of plug-ins to the Rails framework.
*<tt>performance</tt> directory: Contains scripts used by the programmer to help understand the performance characteristics of the application being built.

Rails 3 does away with all of these scripts and compiles them all into a single script named <tt>rails</tt>. With this script, the programmer can access all of the functionality that was available with the separate scripts. To make things even easier, the necessity to call this script outright is even unnecessary. By using the operating systems installed <tt>'''rails'''</tt> command (ex, <tt>/usr/bin/rails</tt> on Linux systems) in the root of any Rails 3 application, it will know to call this script.

==Gem Dependencies==

The ability to extend the Rails framework using a Gem is a very powerful feature. In Rails 2, the <tt>config/environment.rb</tt> file had to be edited in order to tell the Rails application to require specific Gems using the <tt>'''config.gem'''</tt> method. To ensure that the Gems were actually installed on the system running the Rails application, the programmer had to execute the <tt>rake gem:install</tt> command.

Rails 3 does away with the need to have that manual process of installing Gems by utilizing a file named <tt>Gemfile</tt> in the root of the application as well as the Bundler. The Bundler looks at the contents <tt>Gemfile</tt> and automatically installs any Gems that are missing from the system. This allows the programmer to focus on more important issues.

==Routing DSL==

The routing DSL for Rails went through a major reconditioning and has actually been renamed to Action Dispatch. This rewrite took the logic out of the Action Controller and is now a standalone piece of software resulting in a much cleaner implementation. As well, the definition of routes for each application are now named within your Application module instead of the Action Controller. The difference can be seen in the beginning line of the <tt>config/routes.rb</tt> file:

<pre>
# Rails 2
ActionController::Routing::Routes.draw do |map|
map.resources :posts
end

# Rails 3
AppName::Application.routes do
resources :posts
end
</pre>

With all these changes, the <tt>config/routes.rb</tt> file now has a new syntax. Here are some of the major differences<ref>Reza 2010</ref>.

===Default Route===

The differences between the default route are minor between the two versions, but the Rails 3 version is much more explicit, as the parentheses indicate parameters that are optional. Also worth noting is that this route is commented out in Rails 3 by default. The reasoning behind this is that there is a big push for a RESTful architecture with the Rails application and this type of route isn't really recommended for that kind of application. It can be uncommented but be warned that doing so will make all actions in every controller accessible via GET requests.

<pre>
# Rails 2
map.connect ':controller/:action/:id'

# Rails 3
match '/:controller(/:action(/:id))'
</pre>

===Regular Routes===
The way in which a regular route is defined is much more streamlined and readable. In Rails 2, you had to define a key for the controller and action. With Rails 3, this definition is streamlined with a <tt>:to</tt> key where you define in a specific format the controller and action responsible for the request. Here is an example to illustrate this point:

<pre>
# Rails 2
map.connect 'products/:id', :controller => 'products', :action => 'view'

# Rails 3
match 'products/:id', :to => 'catalog#view'
</pre>

===Named Routes===
Setting up named routes has changed a little bit as well. The rules for the regular routes apply here but the way that you define the name of the route has changed. Now, you utilize the <tt>:as</tt> key to define the name of the route as shown here:

<pre>
# Rails 2
map.logout '/logout', :controller => 'sessions', :action => 'destroy'

# Rails 3
match 'logout', :to => 'sessions#destroy', :as => "logout"
</pre>

===Empty Route===
The empty route defines where to route the application when a user navigates to the root of the website (for normal HTML sites, this is the same as the index page). Rails 2 had a quick way of defining it but in true Ruby fashion, Rails 3 makes it even simpler to define this route as you can see here:

<pre>
# Rails 2
map.root :controller => "welcome", :action => 'show'

# Rails 3
root :to => 'welcome#show'
</pre>

===RESTful Resources===
RESTful resources are very important and have been a part of Rails since version 1.2. Utilizing the <tt>rails generate scaffold</tt> command, Rails will generate the route, controller, views and model necessary to have the basic REST functionality for a model. As you can see from the following example, defining a RESTful route is simple in either version. Rails 3 grants you the ability to use this line for multiple resources as well, saving lines of code and making it more readable.

<pre>
# Rails 2
map.resources :products

# Rails 3
# Single resource definition
resources :products
# Multiple resource definitions
resources :products, :categories, :comments
</pre>

Also, Rails 3 provides you with the ability to extend the routing beyond the seven basic RESTful actions. There are multiple ways in which you can extend this functionality:

<pre>
# Defining extra collection RESTful actions within a block.
resources :products do
collection do
get :sold
post :on_offer
end

# An inline extension.
resources :products do
get :sold, :on => :member
end
</pre>

==Active Record==
Active Record, like all of the core Rails components, got a major overhaul.

===Arel and the Query Interface===
The most prominent changes made that will be apparent to developers will be the integration with [https://github.com/nkallen/arel Arel]. With this integration, all of the core methods for Active Record return relations, allowing them to be chained together to develop complex queries. A full list and their functionality can be found in the [http://guides.rubyonrails.org/active_record_querying.html Rails Guide]. This will take the place of the options hash that would normally get passed in to one of the Active Record methods. To illustrate this, say we wanted to get a list of the first 10 products ordered alphabetically:

<pre>
# Rails 2
Product.find(:order => "name DESC", :limit => 10)

# Rails 3
Product.order("name DESC").limit(10)
</pre>

Also, there are a lot of methods that are losing the options parameter in their definitions<ref>Naik 2010</ref>, including query methods find and all as well as calculation methods count and average. Also, the <tt>:all</tt> and <tt>:first</tt> parameters for the find method are being deprecated in favor of the <tt>all</tt> and <tt>first</tt> methods. Here are some examples of how things are changing:

<pre>
# Changes to the find method.
# Rails 2
Product.find(:all)
Product.find(:first)

# Rails 3
Product.all
Product.first

# Examples of method options being removed.
# Rails 2
Product.all(:joins => :categories)

# Rails 3
Product.joins("categories")
</pre>

===Named Scopes===
The <tt>named_scope</tt> definition has been changed to just <tt>scope</tt>. The options hash is also being deprecated and should be replaced with the new methods provided by the Arel integration. Translating existing Rails 2 named scopes is easy enough:

<pre>
# Rails 2
class Product
named_scope :food, :conditions => { :type => "food" }
end

# Rails 3
class Product
scope :food, where(:type => "food")
end
</pre>

==JavaScript Support<ref>Gadbois 2010</ref>==

There are many JavaScript libraries available to programmers to make their web applications more dynamic and smooth looking. Whenever you created a Rails 2 application, it would automatically install the Prototype and Script.aculo.us frameworks. Rails also provided helpers for these two JavaScript frameworks so that a few method calls were all that you needed to make your application more fluid.

Rails 3 introduces the idea of Unobtrusive JavaScript (UJS). The JavaScript becomes unobtrusive by not being written in with the HTML objects producing cleaner code that is easier to debug. This is mostly done with the utilization of HTML 5 custom attributes such as data-method, data-confirm, data-remote and data-disable-with:

<pre>
<form action="http://host.com" id="create-post" method="post" data-remote="true" data-confirm="Are you sure you want to submit?">
</pre>

By doing this, it also frees Rails from being dependent on the Prototype framework, allowing it to become ''JavaScript framework agnostic''. With its current implementation, the framework can support Prototype, jQuery and MooTools.

It might also be helpful to point out that as of Rails 3.1, the jQuery framework has replaced Prototype as the default JavaScript framework. Programmers that wish to still use Prototype must remember to specify this when they create the Rails application.

<pre>
rails new myapp -j prototype
</pre>

=References=

==Citation Notes==
<references/>

==Full Reference Information==

Gadbois, John. ''Using Unobtrusive JavaScript and AJAX with Rails 3'' http://net.tutsplus.com/tutorials/javascript-ajax/using-unobtrusive-javascript-and-ajax-with-rails-3/ , 2010.

Lindsaar, Mikel. "Ruby on Rails 3.0 Release Notes" http://edgeguides.rubyonrails.org/3_0_release_notes.html

Naik, Pratik. "Active Record Query Interface 3.0" http://m.onkey.org/active-record-query-interface , 2010.

Reza, Rizwan. "The Lowdown on Routes in Rails 3" http://www.engineyard.com/blog/2010/the-lowdown-on-routes-in-rails-3/ , 2010.

Ruby, Sam, Dave Thomas and David Hansson. ''Agile Web Development with Rails: Third Edition'': The Pragmatic Programmers LLC, 2009.