Wednesday, February 6, 2013

Chapter 5: Overloading, Overriding, Runtime type and Object orientation.


Chapter 5: Overloading, Overriding, Runtime type and Object orientation.


Here we can understand following concepts :


  1. Data hiding
  2. Abstraction
  3. Encapsulation
  4. IS-A relationship
  5. Has-A relationship
  6. Method signature
  7. Overloading and Overriding
  8. Static control flow
  9. Instance control flow
  10. Constructor
5.1. Data hiding:
The date should not go out directly. Declare the entire variables as private.
The advantage is to avoid data corruption and achieve security.


5.2. Abstraction:
Hiding implementation details is the concept of abstraction.
Advantages are security, enhancement, maintainability and modularity.
The main advantage of abstraction is with out effecting outside world we are allow to change the internal implementation


5.3. Encapsulation:
If any class follows abstraction and data hiding that class is said to be encapsulated class.

Encapsulation = data hiding + abstraction.

Hiding the data behind the methods is the central concept of encapsulation.
We are not allowed to access date directly from outside. We should access through getter and setter methods.

Advantages are security, maintainability, modularity and enhancement


Tightly encapsulated class: A class is said to be tightly encapsulated class if and only
if all the data members must be declared as the private.

Ex:

1. class X
   {
   private int i=10; -------Compile successfully
   }
2. class Y extends X
    {
      int y=10; -------Compile time exception
    }
3. class Z
   {
      private int a=10;


      private int getA(){return a;} ----------- Compile successfully
      private void seta(){this.a=0;}
   }
4. class L
  {
    int l=10; ----------------------- Compile time exception.
  }
5. class M extends L
   {
     private int m=20; -------------- Compile time exception.
   }
6. class N extends M
   {
    private int n=30; -------------------- Compile time exception
    }

If the parent class is not tightly encapsulated no child class is tightly encapsulated.


5.4. IS-A relationship:

IS-A relationship is also known as inheritance.
extend is the keyword to implement IS-A relationship.
Ex: Animal extends Dog, then Dog is a Animal.
Advantage is reusability of the code.
Until certain level inheritance is the advantage feature once it got saturated it will create
side effects.

A--------B--------C--------D--------E--------F--------G

G g = new G()


For the above statement,
For creating instance of G, internally it will create F, E, D, C, B, A instances.
Creating instances or objects are very costly operation.




5.5. Has-A relationship:

This relationship is called as composition/aggregation
There is no separate keyword for implementing Has-A relationship.
Advantage is re usability.

class Engine
{

-----
--------
m1();
-----
-----

}


class Car
{

Engine e = new Engine(); // class Car has Engine

e.m1();

}


5.6. Method Signature:

Method signature consists of the name of the method followed by arguments (order of
the arguments also considered).
Return type is not a part of method signature in Java.
Within the class there is change of having two methods with the same signature,
violation leads to compile time exception.
Ex:
class Sample
{
public void m1(){}
public int m1() Compile time exception like method m1() already
{ defined
return 10;
}
}

5.7. Method overloading and overriding:

The methods are said to be overloaded if and only if the name of the methods are same
but with different arguments (at least order).
Overloading method resolution will take place at compile time only bases on the reference type. Hence overloading is an example of compile time polymorphism. Overloading is also called static binding or early binding.

5.8. Automatic promotion in overloading:

In the following example s.m1(‘a’); the compiler will check is there any method m1()
with char as the argument in sample class.








If there is no such method then compile automatically promotes to char to the int and it will check is there any method with int as the argument. If there is no such method it will continue the same process for the long followed by float followed by double. If still there is no such method then the compiler will rise a compile time exception saying there is no such method m1 ( ) which can take char as the argument.

In the case of method overloading our concentration is always on the method names (method names must be same) and arguments(must be different, at least order). We never consider return type, access specifier and throws class in the overloading.



Observe the following cases.

Case1:

class A
{
public void m1(Object o)
{
System.out.println(“Object version”);
}
public void m1(String s)
{
System.out.println(“String version”);
}
}
class Sample extends A
{
public static void main(String args[])
{
Sample s = new Sample(); Output
s.m1(null); ---------------------------------------------- String version
}
}

Case 2:

class A
{
public void m1(int i, float f)
{
System.out.println(“int ,float”);
}
public void m1(float f, int i)
{
System.out.println(“float, int”);
}
}
class Sample extends A
{
public static void main(String args[])
{
Sample s = new Sample();
s.m1(10,10.1f); -------------------------Compile successfully
s.m1(10.2f,10); -------------------------Compile successfully
s.m1(10,10); ----------Compile time exception saying reference to m1 is ambiguous
}
}


Case 3:

class Animal
{}
class Monkey extends Animal
{}
class A
{
Public void m1(Animal a)
{
System.out.println(“Animal version”);
}
Public void m1(Monkey m)
{
System.out.println(“Monkey version”);
}
}
class Sample extends A
{
public static void main(String args[])
{
Sample s = new Sample();
s.m1(null); ----------------------------Monkey version
Monkey m = new Monkey();
s.m1(m); -----------------------Monkey version ( if Monkey version is not there
then the out put is Animal version)
Animal a = new Animal();
s.m1(a); -------------------------Animal version
Animal am = new Monkey();
s.ma(am); -------------------------Animal version
}
}
Overloaded methods will resolve at compile time only based on references. We never
consider runtime objects in overloading.


5.9. Method Overriding:
Two methods are said to be overridden if and only if their signatures must be same.
5.9.1. Rules for overriding:
Name of the methods must be same .
Arguments must be the same including order.
Signatures must be same
Return types must be same until 1.4 versions. But in 1.5 versions covariant return types are also allowed.
Final methods cannot be overridden in the child class.
Overriding concept can not apply for private methods. If we want same method name we declare in child class but that is not considered as overridden.


Ex:
class Trailp
{
private void m1()
{
System.out.println(“This is parent tail method”);
}
}
class Trailc extends Trailp
{
private void m1()
{
System.out.println(“This is child trail method”);
}
public static void main(String args[])
{
System.out.println(“This is main method”);
Trailc tc = new Trailc();
tc.m1();
}
}
While overriding decreasing the access specifier is not allowed, violation leads to compile
time exception.
Ex:
class Trailp
{
public void m1()
{
System.out.println(“This is parent tail method”);
}
}
class Trailc extends Trailp
{
private void m1() ------------Compile time exception ( while overriding decreasing the
{ access specifier is not allowed)
System.out.println(“This is child trail method”);
}
public static void main(String args[])
{
System.out.println(“This is main method”);
Trailc tc = new Trailc();
tc.m1();
}
}



5.10. Access specifier priority: