Data hiding

Data hiding: making variable private

Abstraction (ATM)

Main advantages of abstraction are.

1. We can achieve security because we are not highlighting our internal implementation.
2. Without effecting outside person we are able to perform any kind of Changes to our internal
systems.

Encapsulation
Encapsulation: the process of binding data members and method into a Single unit is
encapsulation.it is a combination of data hiding and Abstraction.

Note: a class is said to be tightly encapsulated if and only if each And every variable declared as
private.Whether class contains corresponding getter () or setter () Methods or not and whether
these methods are declared as public or not These things we are not required to check.
Note2: if the parent class is not tightly encapsulated than no child Class will be tightly
encapsulated.

Inheritance: is- A relationship

if any class doesn’t extend any other class than it is a direct child class of object. Else if class A
extend Class B than it will be child class of Class B and it will result in multilevel inheritance where
Class B is the child class of Object.
There may be chance of Ambiguity problem hence java won’t provide support from multiple
inheritance.
Note: An interface can extend any no of interface simultaneously hence java provide support for
multiple inheritance with respect to interfaces.
Eg: interface c extends a,b
ques : why ambiguity problem won’t be there in interfaces.
Ans: even though multiple method declaration is available but implementation is unique hence
there is no chance of ambiguity problem in interfaces.
NOte: strictly speaking we cannot get inheritance via interfaces since inheritance means code
reusability but interface contain only method definitions.
Questions : (Cyclic inheritance is not allowed in java)
1. Class A extends A (invalid) -- compile time error
2.(invalid) Class A extends B
Class B extends A
Inheritance: has-A relation

Difference between Composition and aggregation

composition: without existing container object if there is no chance of existing contain objects
than container and contained objects are strongly associated and this strong association is
nothing but composition

E.g.: university consist of several departments without existing university there is no chance of
existing departments. Hence university and department are strongly associated and this strong
association is nothing but composition
Aggregation: without existing container object if there maybe chance of existing contain objects
than container and contained objects are weekly associated and this weak association is nothing
but aggregation
E.g.: professor and departments
IS-A Versus Has-A relationship
If we want total functionality of a class automatically. Than we should go for IS-A relationship
Eg : student IS- A Person
If we want partial functionality of a class. Than we should go for has-A relationship
Eg: student HAS-A name, id etc
Method Signature
In java method signature consist of method names followed by argument types only.
Note: Compiler will use method signature to resolve method calls
A class cannot have two methods with same method signature in same class
Method Overloading:
(early binding: static binding: compile type polymorphism)
In C language method overloading concept is not available hence we can’t declare multiple
methods with same name but different args type. If there is change in args type compulsory we
need to go for new method which increases complexity of programing
Note: in overloading compiler is responsible to perform method resolution based on reference
type. Runtype object doesn’t play any role in method overloading

Case1: automatic promotion in overloading

By resolving overloaded methods if exact match method is not available than we wont get any
compile time error immediately. First it will promote arg to next level and check whether
matched method is available or not if a matched method is available than it will be considered
and if the matched method is not available than complier promotes args once again to the next
level this process will be continued until all possible promotions still if the matched method is
not available than we will get compile time error. The following are all possible promotions in
overloading.

Byte—short—int—long—float—double
Char--int--long—float—double
This process is called automatic promotion in overloading

Case 2:
While resolving overloaded methods compiler will always keep the precedence for child type
argument when compared with parent type argument methods

o/p: string method called

public class OverloadingAutoPromotion {
public static void main(String[] args) {
// TODO Auto-generated method stub
OverloadingAutoPromotion o = new OverloadingAutoPromotion();
char c = 10;
o.m1(null);
}

private void m1(Object object) {

// TODO Auto-generated method stub
System.out.println("object method called");
}

private void m1(String s) {

// TODO Auto-generated method stub
System.out.println("string method called");

Case 3

It will result in compile time error: reference to m1 is ambigious since the String arg method and
StringBuffer args method both are at same level
public class OverloadingAutoPromotion {
public static void main(String[] args) {
// TODO Auto-generated method stub
OverloadingAutoPromotion o = new OverloadingAutoPromotion();
char c = 10;
o.m1(null);
}

private void m1(String s) {

// TODO Auto-generated method stub
System.out.println("string method called");
}

private void m1(StringBuffer sb) {

// TODO Auto-generated method stub
System.out.println("stringbuffer method called");
}
}
Case 4
o.m1(10f,10f): The method m1(float, int) in the type OverloadingAutoPromotion is not applicable
for the arguments (float, float)

o.m1(10,10): The method m1(int, float) is ambiguous for the type OverloadingAutoPromotion
public class OverloadingAutoPromotion {
public static void main(String[] args) {
// TODO Auto-generated method stub
OverloadingAutoPromotion o = new OverloadingAutoPromotion();
char c = 10;
o.m1(10,10);
o.m1(10f,10f);
}

private void m1(int i, float f) {

// TODO Auto-generated method stub
System.out.println("int-float method called");
}

private void m1(float f,int i) {

// TODO Auto-generated method stub
System.out.println("float-int method called");
}
}
Case 5
Note: in general var..arg method will get least priority i.e. if no other method matched than only
var..arg method will get the chance it is exactly same as default case inside switch.
public class OverloadingAutoPromotion {

public static void main(String[] args) {

// TODO Auto-generated method stub
OverloadingAutoPromotion o = new OverloadingAutoPromotion();
o.m1(10);
}

private void m1(int... x){

System.out.println("var…arg method");
}

private void m1(int x){

System.out.println("whereargs method");
}
Case 6
in overloading compiler is responsible to perform method resolution based on reference type.
Runtype object doesn’t play any role in method overloading
public class Animal {

}
class Monkey extends Animal{

}
class Test12345{

public static void main(String[] args) {

Animal a = new Animal();
Monkey m = new Monkey();
Animal am = new Monkey();

Test12345 t = new Test12345();

t.m1(am); // Animal args method will be called since the reference type is of animal.
}

public void m1(Animal a){

System.out.println("Animal method called");
}

public void m1(Monkey m){

System.out.println("monkey method called");

}

}
Overriding: ONLY APPLICABLE FOR METHODS NOT TO VARIABLES
Note: Method resolution always taken care by JVM based on run time object and hence
overriding is also considered as run time polymorphism or dynamic polymorphism or late binding.
JVM will check if the runtime object is parent object or child object

Rules for Overriding

1. Method name and arg type must be matched i.e. method signature must be same.
2. Return Type Rule: In overriding return type must be same but this rule is applicable until
1.4 version only from 1.5 version onwards we can take co-variant Return types according
to this child class method return type need not be same as parent method return type.
Its child type also allowed
Note: for Primitive types (Int, float, double,etc) co-variant concept is not applicable.it is
only applicable for object type.
3. Modifiers: parent class private methods not available to the child and hence overriding
concept not applicable for private methods.
 a. Based on our requirement we can define exactly same private method in child
class it is valid but not overriding.
4. Final Keyword: We can’t override parent class final methods on child classes. If we are
trying to override we will get compile time error.
5. Abstract Methods: parent Class abstract method we should compulsory override in child
class to provide implementation.
a. We can override Non-Abstract method as Abstract. The advantage of this
approach is we can stop the availability of parent method implementation to the
next level child classes
6. In overriding the following modifiers won’t keep any restrictions
a. Synchronized
b. Native
c. strictfp
7. while overriding we cannot reduce scope of access modifiers but we can increase the
scope.
Public>>Protected(within package but possible in child class outside
package)>>Default(within package)>>Private

Note: overriding not applicable for Private Methods.

8. Exceptions: if child class method throws any CHECKED EXCEPTION compulsory Parent
class method should throw the same CHECKED EXCEPTION or its Parent. Otherwise we
will get compile time error. But there are no restrictions for unchecked exception
9. Static:

a. We can’t override a static method as non-static otherwise we will get compile time
error.
b. Similarly we cannot override a non-static method as static
c. Method hiding. : If both parent and child class method are static than we won’t
get any compile time error. It seems overriding concept applicable for static
methods but it is not overriding but it is method hiding.
10. Method hiding: All rules of method hiding are exactly same as overriding except the
following differences
S.No. Method hiding Overriding
1 Both parent and child Both parent and child
method should be static. method should be non-static.

2 Compiler is responsible for JVM is always responsible for

method resolution based on
reference type
3 It is also known as compile
time polymorphism, static
polymorphism, early binding
method resolution based on
run time object
It is also known as run time
polymorphism, dynamic
polymorphism, late binding
Overriding with respect to varargs Method

We can override vararg method with another vararg method only. If we are trying to override
with normal methods than it will become OVERLOADING but not OVERRIDDING.
IF we replace child method with vararg method than it will become OVERIDDING.

Variable Resolution:
Always takes care by compiler based on reference type. Irrespective of whether the variable is
static or non-static ( overriding concept applicable only for methods but not for variables)
Note :
In overloading we have to check only method names (must be same) and argument types(must
be different). We are not required to check remaning like return types access modifier etc.
But in overriding every thing we have to check like method names, arg types, return types, access
modifiers, throws class, etc
Note: static and abstract combination not allow in methods.
Polymorphism:
Parent class ref can be used to hold child object. But by using that reference we can call only the
methods available in parent class and we can’t call child specific methods.
BUT by using child reference we can call both parent and child class methods.

Child c = new Child()

c. m1();
c.m2();
Question: when we should go for parent reference to hold child object.
Ans: If we don’t know exact run time type of object than we should go for Parent reference.
For eg: the first element present in the list can be of any type. It may be student object, customer
object, string object or string buffer object hence the return type of get() method is object which
can hold any object.
List I;
Object 0 = l. get(0);
Coupling

The above components is said to be tightly coupled with each other because dependency
between the components is more.

Tightly coupling is not a good programing practice. Because it has several serious disadvantages.

Note: for every component a clear well defined functionality is defined than that component is
said to be follow high cohesion.
It is always a good programing practice.