Интерфейс внутри класса

#java #oop #class #interface

#java #ооп #класс #интерфейс

Вопрос:

Q1. Могу ли я иметь интерфейс внутри класса на Java?

Q2. Могу ли я иметь класс внутри интерфейса?

Если да, то в каких ситуациях следует использовать такие классы / интерфейсы.

Ответ №1:

Q1. Да Q2. Да.

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

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

Один из примеров последнего:

 public interface EmailService {

    void send(EmailDetails details);

    class EmailDetails {
        private String from;
        private String to;
        private String messageTemplate;
        // etc...
    }
}
  

Комментарии:

1. Итак, как переменная, определенная в интерфейсе, является статической, этот класс также является статическим или что-то в этом роде??? Как мне создать экземпляр этого класса внутри интерфейса и как мне получить к нему доступ к любому фрагменту кода для того же?

2. new EmailService.EmailDetails()

3. Возможно, представляет некоторый интерес, внутренний класс может предоставлять общие операции в форме static void sendLater(EmailService details, Date d){...} разрешения es.EmailDetails.sendLater(this,dateLater);

Ответ №2:

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

Пока Java 8 не выйдет…

Смотрите http://datumedge.blogspot.hu/2012/06/java-8-lambdas.html (Методы по умолчанию)

Обходной путь для этого:

 public interface I
{
    public Class U{
        public static void complexFunction(I i, String s){
             i.f();
             i.g(s) 
        }
    }
}
  

Затем вы можете легко вызвать общую функциональность (после импорта ввода-вывода)

 U.complexFunction(i,"my params...");
  

Может быть дополнительно доработан с помощью более типичного кодирования:

 public interface I
{
    public Class U{
        I me;
        U(I me){
            this.me = me;
        }

        public void complexFunction(String s){
             me.f();
             me.g(s) 
        }
    }
    U getUtilities();
}

class implementationOfI implements I{
    U u=new U(this);
    U getUtilities(){ return u; }
}
  

вызывая затем

 I i = new implementationOfI();
i.getUtilities().complexFunction(s);
  

Еще один пикантный трюк

  1. предоставляет U как абстрактный, давая возможность локальной реализации определенных функций для U…
  2. переопределение U локальным классом и локальным конструктором с использованием I.это вместо принудительной передачи параметров…
  3. используя статический U … однако тогда каждая операция должна получать I i в качестве параметра…
  4. использование enum вместо class только для статических функций, не требующих каких-либо дополнительных объектов (эквивалентно первому методу)

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