Преимущества интерфейса в Java - PullRequest
16 голосов
/ 30 июня 2011

У меня простой вопрос: есть ли преимущество использования интерфейсов, если они реализованы одним классом?
Я всегда думал, что интерфейсы хороши, только когда есть несколько реализаций этого интерфейса.

Спасибо.

Ответы [ 6 ]

11 голосов
/ 30 июня 2011

Одним словом: нет. Контракт, который означает интерфейс, может быть указан непосредственно в вашем единственном классе.

Если вам ясно, что в будущем вам не понадобится другая реализация тех же методов, вы можете избежать определения интерфейса.

Конечно, проблема здесь заключается в предложении «в будущем». Если проект небольшой, без длительного периода разработки / обновления и четко определен, вы можете быть почти уверены в том, что потребуется в будущем.

Если проект длительный, поскольку, вероятно, он будет подвергнут изменениям, вам придется учитывать:

  • вероятность того, что вам наконец-то нужен интерфейс.
  • вероятность того, что вы знаете, какие методы понадобятся интерфейсу в будущем.
  • стоимость создания интерфейса сейчас по сравнению с рефакторингом в будущем.
6 голосов
/ 30 июня 2011

Учтите, что сейчас может быть только одна реализация, но в будущем может появиться еще больше.Кроме того, используя интерфейс, вы можете избежать создания зависимости от конкретного класса, используя только интерфейс.Затем, позже, если вы решите изменить реализацию, вы можете создать новую, которая реализует интерфейс без негативного влияния на другой код, который зависит только от вашего интерфейса.

Обратите внимание:

public interface SomeInterface {...}

public class AConsumerOfSomeInterface {
    private SomeInterface service;

    public AConsumerOfSomeInterface(SomeInterface theImplementation) {
        service = theImplementation;
    }
    //some code which uses the service
}

Теперь вы можете поменять местами реализации в будущем, не меняя этот класс.Поскольку это легко сделать, имеет смысл использовать интерфейсы, даже если вы не думаете, что вам нужен.

2 голосов
/ 30 июня 2011

Я хотел бы добавить еще один момент: Интерфейс помогает в Шаблон прокси .

В веб-приложении этот прокси очень помогает для абстракции. Я новичок в веб-приложении, но обычно я разрабатываю свой сервис на уровне интерфейса. В сборке веб-приложения с Wicket у меня есть, скажем, интерфейс Afrodite и класс AfroditeImpl в качестве сервисного уровня, инициализированного из applicationContext как Spring Bean. Затем мы можем получить все методы, определенные в Afrodite и реализованные в AfroditeImpl со всех веб-страниц с помощью

AfroditeApplication application = (AfroditeApplication)getApplication();
Afrodite afrodite = application.getAfrodite();
// Now call the service layer's methods by afrodite

Схема:

public interface Afrodite {

}

public class AfroditeImpl implements Afrodite {

}

public class AfroditeApplication extends WebApplication {

    Afrodite afrodite;

    public Afrodite getAfrodite() {
        return afrodite;
    }

    @Override
    public void init() {        
        super.init();
        ApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(getServletContext());        
        afrodite = (Afrodite) applicationContext.getBean("afrodite");
    }
}

Надеюсь, это поможет.

2 голосов
/ 30 июня 2011

Интерфейсы - это способ разъединения отдельных программных компонентов.Конечно, вы можете использовать базу данных Oracle для хранения всех ваших данных сегодня , так почему бы не отказаться от всех ваших интерфейсов DAO?

Ответ таков: сильная связь с чем угодно может вернуться и укусить вас в будущем.Что если в следующем году вы захотите использовать какой-нибудь облачный сервис для хранения данных?Если вы закодировали интерфейс DAO, вы можете просто представить новую облачную реализацию и подключить ее напрямую. Ваше приложение слабо связано, поэтому не нужно менять.

1 голос
/ 30 июня 2011

есть ли преимущество использования интерфейсы, если они реализованы один класс?

Если ваш интерфейс реализован только одним классом, и вы на 100% уверены, что НИКОГДА не почувствуете необходимость добавить еще одну реализацию, то никаких преимуществ нет.

Во всяком случае, я думаю, есть другая ситуация, которую нужно иметь в виду. Предположим, у вас есть класс, который делает нечто большее, чем то, что вы хотите представить другому клиентскому классу. Чем интерфейс может быть использован для ограничения методов вашего класса, которые клиент может вызывать:

public interface clientInterface{
     public foo();
     public bar();
}

public class yourClass implements clientInterface{
     public foo(){}
     public bar(){}

     public doSomethingElse(){}
}

public class clientSideFactory{
     public clientInterface getClass(){
               return new yourClass();
     }
}
public class internalSideFactory{
     public clientClass getClass(){
            return new yourClass();
     }
}
}

В ситуации, показанной выше, даже если у вас есть единственная реализация (clientClass) интерфейса clientInterface, это полезно для возврата клиентскому классу, который должен видеть только ограниченную часть вашего класса (ограничивая видимость вашего класс полной реализации).

1 голос
/ 30 июня 2011

Спросите себя, есть ли реальная возможность, что в ближайшем будущем будет более одной реализации

Вы можете легко добавить интерфейс при необходимости, иногда несколько интерфейсов.

Единственный случай, когда я создаю интерфейсы даже для одного класса, это , чтобы различать API для общего использования и специализированный API (например, для тестирования, мониторинга).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...