Java: How do you access a parent class method two levels down?

We don't: it violates encapsulation.

It is fine to say, "No, I don't want my own behavior - I want my parent's behavior" because it's assumed that you'll only do so when it maintains your own state correctly.

However, you can't bypass your parent's behavior - that would stop it from enforcing its own consistency. If the parent class wants to allow you to call the grandparent method directly, it can expose that via a separate method... but that's up to the parent class.

Workaround using flag:

package com.java.oops;

/**

 * Grand Parent Class

 */

class AClass {

     public void method(boolean gpFlag) {

           System.out.println("Class A");

     }

}

/**

 * Parent Class.

 */

class BClass extends AClass {

     public void method(boolean gpFlag) {

           super.method(gpFlag);

           if(gpFlag) {

                return;

           }

           System.out.println("Class B");

     }

}

/**

 * Child Class.

 */

class CClass extends BClass {

     public void method(boolean gpFlag) {

           super.method(gpFlag);

           System.out.println("Class C");

     }

}

public class CallGrandParent {

     public static void main(String[] args) {

           CClass c = new CClass();

           boolean gpFlag = true;

           c.method(gpFlag);

     }

}

Output:

Class A

Class C

When to use interface and abstract class?

An abstract class can have shared state or functionality.

An interface is only a promise to provide the state or functionality.

A good abstract class will reduce the amount of code that has to be rewritten because its functionality or state can be shared. The interface has no defined information to be shared.

In case of abstract classes we are defining characteristics of an object type, specifying what an object is but in the case of an interface we define a capability and we bond to provide that capability, we are talking about establishing a contract about what the object can do.

Abstract Class vs Interface

An interface is a "contract". If a class implements an interface it has to propose all the services listed in the interface.

An abstract class is a skeleton. It defines a certain way its extended classes will work while letting them some free space (the abstract methods) to be unique.

A pure abstract class doing the same thing as an interface but have the problem of unique extending so, for me, it have no interest.

Every interface is implicitly abstract

Every method declaration in the body of interface is implicitly abstract and public.

An abstract class has methods that can contain implementation. Abstract methods can be either public, protected or default access (package visible). Unlike interfaces abstract classes can contain fields that are not static and final.

	Interface	Abstract Class
Extend Class	No	Yes
Extend Abstract Class	No	Yes
Implement Interface	Yes(Extend Interface)	Yes
Variables	public static final	public/protected/private/static/final/transient/volatile
Contain Non-Public Method	No	Yes
Contain Abstract Method	Yes	No

Composition (HAS-A) Relationship

Composition in java can be achieved by using instance variables that refers to other objects.

Example: Car has Engine, or House has Bathroom, a Person has a Job.

class Engine {

     private String model;

     private long power;

     public long getPower() {

           return power;

     }

     public void setPower(long power) {

           this.power = power;

     }

     public String getModel() {

           return model;

     }

     public voidsetModel(String model) {

           this.model = model;

     }  

}

class Car {

     //composition has-a relationship

     private Engine engine;

     public Car() {

           this.engine = new Engine();

           engine.setPower(1000L);

     }

     public long getPower() {

           return engine.getPower();

     }

}

public classCompositionTest {

     public static voidmain(String[] args) {

           Car car = new Car();

           System.out.println("Engine Power in cc #"+car.getPower());

     }

}

Notice that above test program is not affected by any change in the Engine object. If you are looking for code reuse and the relationship between two classes is has-a then you should use composition rather than inheritance.

Biggest benefit of using composition is that we can control the visibility of other object to client classes and reuse only what we need.

Interface-segregation principle

What is the point in selling a horse saddle for one who does not own a horse?

The interface segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Clients should not be forced to depend upon methods that they don't use.

ISP is intended to keep a system decoupled and thus easier to refactor, change, and redeploy.

When we design an application we should take care how we are going to make abstract a module which contains several submodules. Considering the module implemented by a class, we can have an abstraction of the system done in an interface. But if we want to extend our application adding another module that contains only some of the sub-modules of the original system, we are forced to implement the full interface and to write some dummy methods. Such an interface is named fat interface or polluted interface. Having interface pollution is not a good solution and might induce inappropriate behavior in the system.

//interface segregation principle - bad example

interface IWorker {

    

     public void work();

     public void eat();

}

class Worker implements IWorker {

     public void work() {

           // ....working

     }

     public void eat() {

           // ...... eating in lunch break

     }

}

class Robot implements IWorker {

     public void work() {

           //.... working much more

     }

     /** Dummy implementation while robot will not eat lunch.*/

     public void eat() {

           //.... eating in lunch break

     }

}

class Manager {

     IWorker worker;

     public void setWorker(IWorker w) {

           worker=w;

     }

     public void manage() {

           worker.work();

     }

}

If the design is already done fat interfaces can be segregated using the Adapter pattern.

// interface segregation principle - good example

interface IWorker extends IFeedable, IWorkable {

}

interface IWorkable {

     public void work();

}

interface IFeedable{

     public void eat();

}

class Worker implements IWorkable, IFeedable {

     public void work() {

           // ....working

     }

     public void eat() {

           //.... eating in lunch break

     }

}

class Robot implements IWorkable {

     public void work() {

           // ....working

     }

}

class Manager {

     IWorker worker;

     public void setWorker(IWorker w) {

           worker=w;

     }

     public void manage() {

           worker.work();

     }

}