Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T13:58:10Z

Srajago3: /* Conclusion */

=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
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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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] 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/>

==Additional Resources==
*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-03T13:56:36Z

Srajago3: /* Conclusion */

=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
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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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 Liskov Substitution Principle 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/>

==Additional Resources==
*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-03T13:47:26Z

Srajago3:

=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
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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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==
A similar interface (that is, similar method signatures) is not sufficient for an elegant 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.
The Principle of Least Astonishment: If a client
thinks he has a reference to an object of type A
but actually has a reference to an object of sub-
type B, there should be no surprises when he
sends messages to the object.
Liskov Substitution Principle: It is acceptable to
make a class B a subclass of class A or to make
B an implementer of interface A only if, for ev-
ery method in both A’s and B’s interfaces, B’s
method accepts as input all the values that A’s
method accepts (and possibly more) and does
everything with those values that A’s method
does (and possibly more).
A class B that is identical to another class A
except that it has extra restrictions on its state
should not be a subclass of A unless both classes
are immutable.
Consider removing from your design any classes
that provide little or no unique behavior.
If class B models a role played by class A, es-
pecially a temporary role, then B should not be
a subclass of A. Instead referencing should be
used.
Inheritance between a superclass A and a sub-
class B is appropriate if it promotes code reuse,
each object of class B “is an” object of class A,
the public interface of class B includes the in-
terface of class A and the behavior of the meth-
ods in this interface in both classes is similar in
both classes, and there is a need for polymor-
phism to allow a variable of type A to refer to
an object of type B. Otherwise, inheritance is
probably inappropriate.
Inheritance makes it hard to follow the flow of
execution through the code of a program, and it
makes it hard for the programmer to change one
of the classes in the hierarchy without affecting
the others.
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 associ-
ated by inheritance either directly or through a
common abstract class or interface.
When designing a class B that will be very simi-
lar 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/>

==Additional Resources==
*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-03T05:43:30Z

Srajago3: /* 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. 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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

==Additional Resources==
*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-03T05:42:36Z

Srajago3: /* 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. 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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

==Additional Resources==
*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
*
*
*
*

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:37:52Z

Srajago3:

=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
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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

==Additional Resources==
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:28:37Z

Srajago3: /* External Links */

=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 ==
'''

===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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

==Additional Resources==
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:28:19Z

Srajago3: /* External Links */

=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 ==
'''

===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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

== External Links ==

==Additional Resources==
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://
*http://

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:25:56Z

Srajago3: /* When to use Inheritance: Lecture 17 */

=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 ==
'''

===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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:22:59Z

Srajago3:

=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 ==
'''

===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<ref>
http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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>
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:20:43Z

Srajago3:

=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 ==
'''

===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<ref> Tips for Effective Software Reuse
http://http://msdn.microsoft.com/en-us/library/27db6csx(v=vs.80).aspx </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> Tips for Effective Software Reuse
http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:17:57Z

Srajago3:

=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 ==
'''

===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<ref> Tips for Effective Software Reuse
http://http://www.kev.pulo.com.au/pp/RESOURCES/C++-FAQ/proper-inheritance.html#[21.6] </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.

|}

=References=

==Citation Notes==
<references/>

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:10:50Z

Srajago3:

=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 ==
'''

===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 ==
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.

|}

=References=

==Citation Notes==
<references/>

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:05:39Z

Srajago3:

== 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 ==
'''

===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 ==
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.

|}

=References=

==Citation Notes==
<references/>

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch17 5b br

2011-11-03T05:04:41Z

Srajago3:

== 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 ==
'''

===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/>

== External Links ==

References:

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-27T23:23:29Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Syntactic Notation ==
'''
There 2 common syntax for getters and setters available in programming languages:

Method Call:
<pre>
value = ObjectName.getAttribute();

ObjectName.setAttribute(val);
</pre>
In the above notation a getter is the same as any other instance method call. Its common for the getters and setters to be defined as public methods.

Instance Variables:
<pre>
ObjectName.Field = Value;

Value = ObjectName.Field;
</pre>

In this notation getters and setters looks like a accessing a class field. In most languages, internally this would invoke a method which would behave very similar to the getter method call described above. This syntactic notation offers a convenience of using intuitive syntax of getting or setting a variable.
'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* [http://java.about.com/od/workingwithobjects/a/accessormutator.htm Encapsulate] the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''

== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* The code is much [http://www.dotnetspider.com/tutorials/DotNet-Tutorial-273.aspx cleaner] when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx fine-grained] access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''

== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
'Getters' and 'Setters' allow you to effectively protect your data. This is a technique used greatly when creating classes in C++. The getters and setters are usually public and the variables are made private. The reason for it is the data members are not accessible outside the class. For each variable, a get method will return its value and a set method will set the value.The reason for not editing the methods directly is twofold. Firstly, if you decide that some action should be taken every time you change the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 JavaScript] supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
In [http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Flex] it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:
public var firstName:String;
If the internal implementation of getting or setting the firstName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:
private var _firstName:String;

Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var firstName:String;
private var _firstName:String;

public function get firstName():String {
return _firstName;
}

public function set fullName(_firstName:String):void {
this._firstName = _firstName;
}
// getters
var1 = obj.firstName;
var2 = obj['firstName'];
// setters
obj.firstName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''

==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a getter method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, we dont want UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()" and getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() getter method can return an object that implements Identity Interface and this Interface includes the method "DrawYourself()". This GetIdentity() call does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Using getters and setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]
<li>[http://java.about.com/od/workingwithobjects/a/accessormutator.htm Accessors and Mutators]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:45:02Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
'Getters' and 'Setters' allow you to effectively protect your data. This is a technique used greatly when creating classes in C++. The getters and setters are usually public and the variables are made private. The reason for it is the data members are not accessible outside the class. For each variable, a get method will return its value and a set method will set the value.The reason for not editing the methods directly is twofold. Firstly, if you decide that some action should be taken every time you change the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 JavaScript] supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
In [http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Flex] it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:
public var firstName:String;
If the internal implementation of getting or setting the firstName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:
private var _firstName:String;

Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var firstName:String;
private var _firstName:String;

public function get firstName():String {
return _firstName;
}

public function set fullName(_firstName:String):void {
this._firstName = _firstName;
}
// getters
var1 = obj.firstName;
var2 = obj['firstName'];
// setters
obj.firstName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''

==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Using getters and setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:39:40Z

Srajago3: /* Actionscript */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
'Getters' and 'Setters' allow you to effectively protect your data. This is a technique used greatly when creating classes in C++. The getters and setters are usually public and the variables are made private. The reason for it is the data members are not accessible outside the class. For each variable, a get method will return its value and a set method will set the value.The reason for not editing the methods directly is twofold. Firstly, if you decide that some action should be taken every time you change the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
In [http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Flex] it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:
public var firstName:String;
If the internal implementation of getting or setting the firstName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:
private var _firstName:String;

Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var firstName:String;
private var _firstName:String;

public function get firstName():String {
return _firstName;
}

public function set fullName(_firstName:String):void {
this._firstName = _firstName;
}
// getters
var1 = obj.firstName;
var2 = obj['firstName'];
// setters
obj.firstName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''

==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Using getters and setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:38:28Z

Srajago3: /* C++ */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
'Getters' and 'Setters' allow you to effectively protect your data. This is a technique used greatly when creating classes in C++. The getters and setters are usually public and the variables are made private. The reason for it is the data members are not accessible outside the class. For each variable, a get method will return its value and a set method will set the value.The reason for not editing the methods directly is twofold. Firstly, if you decide that some action should be taken every time you change the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
In [http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Flex] it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:

public var firstName:String;

If the internal implementation of getting or setting the firstName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:

private var _firstName:String;

Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var firstName:String;
private var _firstName:String;

public function get firstName():String {
return _firstName;
}

public function set fullName(_firstName:String):void {
this._firstName = _firstName;
}
// getters
var1 = obj.firstName;
var2 = obj['firstName'];
// setters
obj.firstName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''

==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Using getters and setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:36:25Z

Srajago3: /* Actionscript */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
In [http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Flex] it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:

public var firstName:String;

If the internal implementation of getting or setting the firstName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:

private var _firstName:String;

Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var firstName:String;
private var _firstName:String;

public function get firstName():String {
return _firstName;
}

public function set fullName(_firstName:String):void {
this._firstName = _firstName;
}
// getters
var1 = obj.firstName;
var2 = obj['firstName'];
// setters
obj.firstName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''

==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Using getters and setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:35:50Z

Srajago3: /* References */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
In Flex it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:

public var firstName:String;

If the internal implementation of getting or setting the firstName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:

private var _firstName:String;

Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var firstName:String;
private var _firstName:String;

public function get firstName():String {
return _firstName;
}

public function set fullName(_firstName:String):void {
this._firstName = _firstName;
}
// getters
var1 = obj.firstName;
var2 = obj['firstName'];
// setters
obj.firstName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''

==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://help.adobe.com/en_US/AS2LCR/Flash_10.0/help.html?content=00000171.html Using getters and setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:33:34Z

Srajago3: /* Actionscript */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
In Flex it is not usually necessary to create the wrapper getter and setting functions on an object because ActionScript supports properties. This means that you can usually just create public properties like:

public var firstName:String;

If the internal implementation of getting or setting the firstName property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class:

private var _firstName:String;

Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var firstName:String;
private var _firstName:String;

public function get firstName():String {
return _firstName;
}

public function set fullName(_firstName:String):void {
this._firstName = _firstName;
}
// getters
var1 = obj.firstName;
var2 = obj['firstName'];
// setters
obj.firstName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''

==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:28:33Z

Srajago3: /* Scala */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala] has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''

===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:27:59Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:23:49Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In [http://www.touch-code-magazine.com/objective-c-properties/ Objective C] we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li>[http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li>[http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li>[http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li>[http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li>[http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:22:22Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in [http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Lua], which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:21:20Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in Lua, which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set PHP] engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:18:41Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your [http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ CFC] and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in Lua, which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, PHP engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:16:06Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your CFC and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx C#], properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in Lua, which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, PHP engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:14:12Z

Srajago3: /* C#: */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your CFC and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
In C#, properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#.yC# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden by polymorphism. They are very useful in GUI programming. The compiler generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''

===Lua===
'''
Getter and Setter functions can be implemented in Lua, which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, PHP engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:12:23Z

Srajago3: /* C++ */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your CFC and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
C# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden polymorphicaly.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''
===Lua===
'''
Getter and Setter functions can be implemented in Lua, which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, PHP engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:10:19Z

Srajago3: /* C++ */

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
In C#, properties are nothing but natural extension of data fields. The properties are an important features added in language level inside C#. They are very useful in GUI programming The compiler actually generates the appropriate getter and setter methods when it parses the C# property syntax.In C#, data encapsulation is possible through either classes or structures. By using various access modifiers like private, public, protected, internal etc it is possible to control the accessibility of the class members. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. This is a good programming practice, since the data fields are not directly accessible out side the class. We must use the set/get methods to access the data fields.
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your CFC and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
C# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden polymorphicaly.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''
===Lua===
'''
Getter and Setter functions can be implemented in Lua, which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, PHP engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]

CSC/ECE 517 Fall 2011/ch1 1h hs

2011-09-21T00:07:59Z

Srajago3:

'''
== What are getters and setters ? ==
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide getter and setter methods to access/modify object data. When writing new classes, it's a good idea to pay attention to the issue of access control. Usually inside a class, we declare a data field as private and will provide a set of public SET and GET methods to access the data fields. Because of this naming convention, accessor methods are more often referred to as getter methods. This is a good programming practice, since the data fields are not directly accessible outside the class. Thus 'Getters' and 'Setters' allow us to effectively protect your data.

'''
== Advantages of getters and setters as method calls ==
'''
For each variable, a get method will return its value and a set method will set the value. Here are the advantages of using getter and setter as method calls:
* Encapsulate the data from accidental / inadvertent modification. The private member variable is not part of the public interface of your class; only the public getter and setter methods are, and you are free to change their implementations without changing the public interface of your class
* If we decide that some action should be taken every time you change/access the value of a particular variable, you only need to edit the set method instead of looking for every place you change the variable. For Instance, we can keep track of how many times a variable is accessed.
* Another reason is that a person using the code can look for all methods starting with get or set instead of looking for specific variables that they need to remember.

'''
== Advantages of getters and getters as variable references(properties) ==
'''
Properties are a robust way to handle object’s data. Properties support accessing the instance variables the same way as calling an instance method. A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. Different languages follow specific syntax for adding a property to a class. Following are the advantages properties:
* the code is much cleaner when accessing a property when compared to Java or C++ which uses 2 separate methods for each instance variable. They are very useful in GUI programming which necessitates using a lot of fields for UI elements
* With properties we have fine-grained access control. For instance we can define a property as abstract thereby forcing the derived class to define that property.
* The main advantage of using properties is that if the internal implementation of getting or setting the property needs to change, then the class can be adapted to have getter and setter functions without changing the external interface of the class. This allows the interface of the object to stay the same even if the underlying implementation of getting and setting the property changes.

Realizing the importance of getters and setters, popular IDEs like Eclipse, Visual studio has a built in mechanism to add getter and setter for a field or to create a property (in C#) for a given field.

'''
== Examples Languages that use getters and setters as method calls: ==
'''
'''
===C++===
'''
<pre>
class A
{
private:
int x_value;

public:
// Getter
int getx_value()
{
return x;
}
// Setter
void setx_value( int x )
{
x_value = x;
}
};
void main()
{
A a;
a.setx_value(5);
cout<<a.getx_value();
}
</pre>
'''

=== Java ===

'''
<pre>
public class BookStore
{
String title;
public String getTitle()
{
return title;
}
// a setter method might check that the value that is being assigned to the variable is legal
public void setTitle( String newTitle )
{
if ( newTitle == null ) // Don't allow null strings as titles!
title = "(Untitled)"; // Use an appropriate default value instead.
else
title = newTitle;
}
}

public static void main()
{
BookStore obj;
obj. setTitle("");
System.out.println(obj.getTitle());
}
Output:
(Untitled)
</pre>
'''

=== Perl ===
'''
Object-oriented languages have the concept of security of data to prevent a programmer from changing an object data directly and so provide accessor methods to modify object data. [http://www.netalive.org/tinkering/serious-perl/#import_extend Perl] does not have private variables but we can still use the concept of getter, setter functions methods.
<pre>
sub setName
{
my ( $self, $Name ) = @_;
$self->{_Name} = $Name;
return $self->{_Name};
}
sub getName
{
my( $self ) = @_;
return $self->{_Name};
}

</pre>

'''

=== ColdFusion ===
'''

If we want to override the getter and setter method, you just need to define those methods in your CFC and ColdFusion will call our method instead of calling the implicit one.The implicit methods can also do some nice validation if you have given the ‘type’ for properties. For instance, if we define a property as numeric and try to provide a try to set a string as its value It will throw a nice error saying “The value cannot be converted to a numeric”.

<pre>
Component Person
{
property name
property age;
property city;
}

<cfscript>
person = new Person();
person.setName("Brad");
person.setAge(46);

writeOutput("Name : #person.getName()#");
writeOutput("Age : #person.getAge()#");
</cfscript>
</pre>

'''
== Examples from Languages that use getters and setters as instance variable references: ==
'''

'''
=== C#: ===
'''
C# also supports static properties, which belongs to the class rather than to the objects of the class. The properties of a Base class can be inherited to a Derived class and can be overridden polymorphicaly.

<pre>class MyClass
{
private int x;
public int X
{
get
{
return x;
}
set
{
x = value;
}
}
}

//Invocation
MyClass mc = new MyClass();
mc.X = 10; // calls set accessor of the property X, and pass 10 as value of the standard field 'value'.
Console.WriteLine(mc.X); // displays 10. Calls the get accessor of the property X.
</pre>

'''
===Lua===
'''
Getter and Setter functions can be implemented in Lua, which is similar to the properties concept in C#. This allows the functions to bind to a property that can be assigned and accessed as a value.

<pre>
class 'Test'
function Test : getLength()
return # self.value
end
function Test : setLength(newLength)
for i = self.length, newLength do
table.insert(self.value, false )
end
end

test = Test({1, 2, 3, 4})
print(test.length)
self.length = property( Test.getLength, Test.setLength )
</pre>
'''
===Ruby===
'''
Ruby simplifies the creation of getters and setters with a little metaprogramming and the methods attr, attr_reader, attr_writer, and attr_accessor, all from the Module class. By supplying the attr method, Ruby provides a way to acces the instances directly.

<pre>
class Person
def initialize(lname, fname)
@lname = lname
@fname = fname
end
attr_reader :lname // creates a getter method
attr_writer :lname // creates a setter method
attr_accessor :fname // creates both getter and setter method
end

x = Person.new("ABC", "XYZ")
print "My name is ", x.fname, " ", x.lname, ".\n"
x.fname = "PQR"
print "My name is ", x.fname, " ", x.lname, ".\n"
</pre>
'''
===Php===
'''
An interesting aspect of php worth noting is that we can assign values to undefined variables. Because of the above limitation, PHP engine provides two magic methods __get() and __set(). __get() is used when value from an undefined variable is to be read and __set() is used when a value is to be assigned to a undefined variable of a class.In the above example when email@domain.com is assigned to the undefined variable $email, the magic method __set() is called. To this __set() method the name of the variable is passed into $dt variable of __set() method and the value i.e. email@domain.com is passed to $vl variable of the __set() method.

<pre><?php
class Customer
{
public $name;
private $data = array();
public function __set($dt, $vl)
{
$this->data[$dt] = $vl;
}
public function __get($dt)
{
return $this->data[$dt];
}
}
$c = new Customer();
$c->name = “Sunil”; // $name is set because its public
$c->email = “email@domain.com”; //assigning email@domain.com to the $email variable.
echo $c->email;
?></pre>

'''
===Objective C===
'''
In Objective C we can define a property using @property directive. @synthesize will create automatically for you a setter and a getter methods for the property which becomes accessible during the run time.

<pre>
// public header file
@interface MyObject : NSObject
{
NSString *make;
NSString* model;
NSNumber* vin;
}
@property (readonly, copy) NSString *language;
@property(readwrite, retain) NSString* make;
@property(readwrite, retain) NSString* model;
@property(readwrite, retain) NSNumber* vin;
@end

#import "SimpleCar.h"
@implementation SimpleCar
@synthesize make, model, vin;
@end
</pre>

'''
=== Python ===
'''

<pre>
class DoubleIt(object):
def _get_value(self):
return self._value * 2
def _set_value(self, value):
self._value = value
value = property(_get_value, _set_value)

# Invocation
x = DoubleIt()

x.value = 10
print x.value

x.value = 'foo'
print x.value

x.value = [1,2,3]
print x.value
</pre>

In the above [http://stefaanlippens.net/python_property_trick python] code, the output is doubled since the getter multiplies the value by 2

'''
=== Javascript ===
'''
Javascript supports accessing getters and setters as variable as properties. Javascript originally used __defineGetter__ and __defineSetter__ syntax to define properties which is depricated as the language evolved. Object.defineProperty is currently used for creating a property.

<pre>
function addDataProperty()
{
var newLine = " ";
var obj = {};

// Add a data property to the object.
Object.defineProperty(obj, "newDataProperty",
{
value: 101,
writable: true,
enumerable: true,
configurable: true
});

// Set the property value.
obj.newDataProperty = 102;
document.write("Property value: " + obj.newDataProperty + newLine);
}
</pre>

'''
=== Scala ===
'''
Scala has some unconventional ideas that provide a solid, well thought out, and an abbreviated syntax to access object properties. This getter code simply defines a method called “age” and returns the “_age” variable. Scala doesn’t require the return keyword. The setter method name is “age_=”. The underscore is a special character in Scala and in this case, allows for a space in the method name which essentially makes the name “age =”. The parentheses and contents dictate the value and type that needs to be passed in. The “:Unit” code is equivalent to returning void. The remaining code is setting the “_age” variable to “value”.

<pre>
class Person() {
// Private age variable, renamed to _age
private var _age = 0
var name = ""

// Getter
def age = _age

// Setter
def age_= (value:Int):Unit = _age = value
}

// We can invoke the setter as follows :
can invoke the setter using the following:
person.age = 99
</pre>

'''
===Smalltalk===
'''
In [http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk] the names of getter methods are usually the same as the name of the instance variable. A colon is added to the end of setter method name e.g. colour:

<pre>
name "gets the value of name"
name:aName "sets name to the value of aName"

address "gets the value of address"
address:anAddress "sets anAddress to the value of anAddress"
</pre>

'''
=== Actionscript ===
'''
Getting or setting the property would call the getter and setter functions instead of accessing the property directly
<pre>
public var fullName:String;
private var _fullName:String;

public function get fullName():String {
return _fullName;
}

public function set fullName(_fullName:String):void {
this._fullName = _fullName;
}
// getters
var1 = obj.fullName;
var2 = obj['fullName'];
// setters
obj.fullName = "Hello World";
obj['fullName'] = "Yes";
</pre>

'''
==Getters and Setters from a different perspective==
'''


A fundamental precept of OO systems is that an object should not expose any of its implementation details. This way, you can change the implementation without changing the code that uses the object. It follows then that in OO systems you should avoid getter and setter functions since they mostly provide access to implementation details. For instance if you need change the return type of a gettr method from int to long to accommodate the big numbers you need to change all the invocations of that getter method. This negates the concept of [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html information hiding]. The same issue arises when you need to change the accessed field’s type. You also have to change the getter’s return type. 
Solution:
Maintainability is inversely proportionate to the amount of data that moves between objects. Thus, its best to minimize data movement as much as possible. The idea is to focus on what you will do rather than how you will do it. Don't ask for the information you need to do the work; ask the object that has the information to do the work for you. Lets use an example to explain this better. While building user interfaces, instead of having UI builder class call methods like "GetAttributes()". Classes can have methods like "DrawYourself()". Classes can have getters that returns an object that implements an interface. In our UI Construction example, GetIdentity() can return a method that implements Identity Interface and this Interface includes the method "DrawYourself()". In this example, GetIdentity() does not return a simple field but a complex object with a defined behavior and the internals of this object is kept hidden 

'''
=== When to Use Getters and Setters ? ===
'''

1. When a getter returns an object that implements an Interface since the interface isolates the class that uses this interface from the implementing class.
2. Generic interfaces like Java Database Connectivity (JDBC) are unaware of how it will be used and in such cases getters are used to provide flexibility

Programmers use getters and setters because of procedural language mindset. A useful design strategy to this end is to center our design in terms of use cases without getters and setters by thinking on the lines of communication or interaction between the objects with well defined behavior.

== Conclusion ==
'''
Getters and setters provide a convenient method to access the instance variables. A lot of new languages have come up with the support for accessing getters and setters as instance variable reference which improves the readability of the code. While such convenient mechanisms are available, it is important to use the getters and setters wisely with the goal of minimizing the data movement between the objects.

'''
== References ==
'''
<li> [http://www.c-sharpcorner.com/UploadFile/rajeshvs/PropertiesInCS11122005001040AM/PropertiesInCS.aspx Understanding properties in C#]
<li> [http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html why getters and setters are evil ]
<li> [http://www.sunilb.com/php/php5-oops-tutorial-__get-and-__set php5 OOPS tutorial]
<li>[http://stefaanlippens.net/python_property_trick python-hiding attribute getters and setters behind standard attribute access]
<li> [http://msdn.microsoft.com/en-us/library/dd548687%28v=vs.94%29.aspx#Y2204 Object.defineProperty Function (JavaScript)]
<li>[http://www.dustinmartin.net/2009/10/getters-and-setters-in-scala/ Getters and Setters in Scala]
<li>[http://www.rupeshk.org/blog/index.php/2009/07/coldfusion-9-implicitgenerated-cfc-methods/ ColdFusion 9 : Implicit/Generated CFC Methods]
<li>[http://www.jamesward.com/2010/05/07/flex-and-java-differences-getters-setters/ Flex and Java Differences: Getters & Setters]
<li> [http://www.touch-code-magazine.com/objective-c-properties/ Objective C properties]
<li>[http://www.tutorials4u.com/smalltalk/smalltalk-tutorial-01.htm#Setter Smalltalk methods]
<li>[http://www.gamedev.net/topic/590548-luabind-properties-within-lua/ Properties in Lua]
<li>[http://www.netalive.org/tinkering/serious-perl/#import_extend Perl ]
<li>[http://http://en.wikibooks.org/wiki/Ruby_Programming/Syntax/Classes#Instance_Variables Ruby]