Interface versus concrete class

Below I have a Person interface, an implementing class and a driver class which initialises the Person with a name and just outputs it again. What is the advantage of using

Person person = new PersonImpl();开发者_运维百科

instead of

PersonImpl person = new PersonImpl();

The interface is supposed to be hiding the implementation? Is this the correct way of using interfaces?

public class Driver {

    public static void main(String [] args)
    {
        Person person = new PersonImpl();
        person.setName("test name");
        System.out.println("Name is "+person.getName());
    }

}


public interface Person {

    public void setName(String name);

    public String getName();

}


public class PersonImpl implements Person{

    private String name;

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

This is the way to use interfaces.

The reason is so you could write another implementation later without changing code that uses Person.

So for now you can use PersonImpl but later you might need a OtherTypeOfPersonImpl.

You could create the new class implementing the same interface, and you could use the new class with any other code that expects a Person.

A good example is the List interface.

There are multiple implementations of List such as ArrayList, LinkedList, etc. Each of these has advantages and disadvantages. By writing code that uses List, you can let each developer decide what type of List works best for them and be able to handle any of them without any changes.

what you did is correct. the advantage in using Person person = new PersonImpl() is that a loose coupling is maintained between the interface and the concrete implementation. PersonImpl person = new PersonImpl() is tightly coupled. and Person person = new Person() won't even compile.

imagine you have a huge application, and a lot of code depends on the PersonImpl object. now suppose i want to change PersonImpl and make a new class, PersonImpl2. now i have to manually scan through the whole project and make changes everywhere. this might even break the code. this is called tight coupling, and is a bad thing. instead, if the rest of the code depended on a Person object, then even if i make a new PersonImpl2 class, things will work fine because PersonImpl2 implements Person.

One advantage I can think of is that you might have 2 very different types of people, but you want to wait until runtime (based on user input, config file, etc.) to decide which one to use. You can do something like this:

Person person = null;
if ...
   person = new PersonImpl();
else 
   person = new PersonImpl2();

It depends on how you want to use Person.

As it stands, you don't gain any real benefit from having it an interface.

However, suppose there were aliens who could also be considered a "Person" because of their behaviors (say "talks(), walks(), thinks(), feels()) that are defined in Person. Now you might want to separate "Person" from "Human" and "Alien" so that individuals from two very different hierarchies -- say "Humans" in the "mammal" hierarchy and "Aliens" in the "arachnid" hierarchy -- could both implement the Person interface.

Using the interface instead of the concrete class would let you change the implementation later.

This about JDBC, all of it is based on interfaces, so the driver can implement it later.

For instance when you use a ResulSet you don't really care how or what underlaying implementation is ( with a Oracle Driver would be something like OracleResultSet, with a MySQL driver could be something like MySQLResultSet ) but you know what methods are available for you to use.

Same goes with List or Map, instead of ArrayList or HashMap