CODEWITHSUNDEEP
javaarchitecture
Brccosta
Brccosta

Reputation: 59

Interface > Abstract Class > Concrete Class pattern

I have found a reference architecture where all domain classes (POJOs) inherit an abstract class and, in turn, the abstract class implements a interface. For instance:

public interface User {  
    public abstract operation1();  
    public abstract operation2();  
    ...  
}  

public abstract class AbstractUser implements User {  
    String name;  
    // only attributes
    ...
}  

public abstract class XyzUser extends AbstractUser {
    ...
}

Do you guys know if this design is some sort of pattern? Can you explain why the architecture was designed like that (Interface --> Abstract Class --> Concrete Class)?

Upvotes: 3

Views: 5319

Answers (6)

Haid
Haid

Reputation: 111

Abstract class is a generalized class for example animal is generalized because abstract method and properties are mentioned here. As many animal has common behaviors and properties.

Concrete Class is a specilized class for a dog which is inherited from animal class (generalized class) to do more specilized for dog only. here we can add some properties and method and even override it's behaviour (from generlized class)

Interface is a task based class which have only abstract methods which can be implemented in abstract class or/and in concrete class to specilized behaviours

Example code here...

    abstract class Animal {
      private String leg;

      abstract void run();
    }

    class Dog extends Animal implements Ibehaviors {

      @Override
      void run() { 
       System.out.println("dog run"); 
      }

      @Override
      void eat() { 
       System.out.println("dog eat"); 
      }

    }


    interface Ibehaviors { 
      void eat(); 
    }

Upvotes: 0

tucuxi
tucuxi

Reputation: 17945

When designing code that is meant to be extended, it is standard practice to rely only on interfaces. To make life easier to extenders, boilerplate code is added to abstract classes extending those interfaces.

This is standard OO practice, rather than a "pattern". A good example can be found in just about all Java Swing widget models. For example TableModel is an interface meant to provide access to a table's data, AbstractTableModel is an abstract class that provides implementations for some simple accounting methods in the interface, and DefaultTableModel is a concrete class that uses, as data storage, an ArrayList.

Upvotes: 1

Debojit Saikia
Debojit Saikia

Reputation: 10632

Here the interface User defines a type: 

public interface User{  
public abstract operation1();  
public abstract operation2();  
...  
}

So implementations of this interface are to be known as of type User.

Now you can provide implementation assistance to the implementers of this interface by using Abstract classes, as interfaces are not permitted to have method implementations. You can provide a skeletal implementation class to go with User interface, which will have default implementations of some of its methods. Here AbstractUser is the skeletal implementation of User:

public abstract class AbstractUser extends IUser  
{ 
public abstract operation1();  
public operation2(){
...
}  
}

You can now write concrete User implementations with the help of AbstractUser:

public class UserImpl extends AbstractUser implements User {
...
}

The Java Collections Framework has a number of skeletal implementation to go along with the main collection interfaces, to minimize the effort required to implement the collection interfaces: AbstractSet, AbstractList, etc.

Upvotes: 1

Arsen Alexanyan
Arsen Alexanyan

Reputation: 3141

I have had this kind of architecture implementation. For example here is snippet of code

public class Category extends CategoryBase implements ICategory

Another is 

public class Functional extends CategoryBase implements ICategory

Here interesting thing is CategoryBase abstract class where You are keeping your common properties and functionalities and You are just reusing them with inheritance

Upvotes: 0

TheLostMind
TheLostMind

Reputation: 36304

This might be the decorator design pattern. U have an interface, an abstract class that implements the interface. Concrete classes extending the abstract class (decorators). and another concrete class that only implements the interface (the object which you decorate). I am not sure. I cannot tell anything without looking at the entire code. But still, have a look at this link. It might help you.

http://javapapers.com/design-patterns/decorator-pattern/

Upvotes: 0

Shoaib Chikate
Shoaib Chikate

Reputation: 8975

First understand what is need of interface, abstract class and concrete class.

Let us take example here:

  public interface Vehicle{
     public void startEngine();
     public void run();
  }


 public abstract class Bus implements Vehicle{
      public void startEngine(){
        System.out.println("Engine Starting of bus");
      }
 }

 public abstract class Plane implements Vehicle{
      public void startEngine(){
        System.out.println("Engine Starting of plane");
      }
 }

 public class VolvoBus extends Bus{

      public void run(){
        System.out.println("Running at 100kmp/h");
      }



 }


 public class NonACBus extends Bus{

      public void run(){
        System.out.println("Running at 50kmp/h");
      }
  }


public class Test{

 public static void main(String[] args){
        VolvoBus volvoBus=new VolvoBus();
        NonACBus nonAcbus=new NonACBus();
        volvoBus.startEngine();
        volvoBus.run();
        nonAcBus.startEngine();
        nonAcBus.run();
      }
  }

See in above example we have code which is common for bus whether its AC bus or Volvo so it is written in Bus class but run() is not common for all so instead of implementing in Bus class it is kept as abstract so its child class will implement that base on there requirement.

My code will explain you better :) Thanks

Upvotes: 3

Related Questions