Oops.docx

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.

4. 5.

6.

7.

a. Based on our requirement we can define exactly same private method in child class it is valid but not overriding. 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. 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 In overriding the following modifiers won’t keep any restrictions a. Synchronized b. Native c. strictfp 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

3

Compiler is responsible for method resolution based on reference type It is also known as compile time polymorphism, static polymorphism, early binding

JVM is always responsible for 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.