В Java 8 интерфейс нарушает концепцию инкапсуляции?

До Java1.7, к счастью, я использовал интерфейсы для реализации инкапсуляции концепции ООП. Если я хочу скрыть реализацию от конечного пользователя, тогда я передам только интерфейс с ними, и они могут вызвать мой API с помощью этого интерфейса, давайте, например, EJB.В Java 8 интерфейс нарушает концепцию инкапсуляции?

Ну выше была действительна до Java 1.7 теперь Java 8, я могу написать реализацию метода в интерфейсе, а также с default и static ключевое слово, например:

public interface Foo { 

    public abstract int someUnimplementedMethod(); 

    default void printMsg() { 
     System.out.println("Hello...!"); 
    } 

    static void sayHello() { 
     System.out.println("Hello...!"); 
    } 

}

это вполне допустимо в Java 1.8 ,

Теперь мой вопрос:

В Java 8 мы пытаемся ввести нечто, называемое частичной инкапсуляцией с default и static методом?
Я знаю, что некоторые из вас будут спорить, если вы не хотите делиться реализацией, то лучше предоставить реализацию default и static в субинтерфейсе и сохранить родительский интерфейс с абстрактным методом, но теперь он не уверен, что если бы я написал интерфейс с абстрактным методом, новичок может написать целую реализацию только в интерфейсе. Поэтому возникает вопрос, а лучше не разрешать реализацию метода в интерфейсе.

Если вы не согласны с моей второй точкой, пожалуйста, предоставьте решение для этого.

Кстати я читал Java documentation, который гласит:

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

источник

2016-02-14 Vishrant

У вас по-прежнему не может быть полей в интерфейсах, поэтому вы не можете иметь состояние, что также означает, что инкапсуляция действительно не имеет никакого отношения к изменениям интерфейсов. –

@LouisWasserman, пожалуйста, прокомментируйте свой комментарий в разделе ответа или укажите полезные ссылки, что вы подразумеваете под «инкапсуляцией, действительно не имеющей ничего общего с изменениями в интерфейсе», это будет полезно. спасибо .. – Vishrant

Связанный: http://stackoverflow.com/questions/27368432/why-does-java-8-not-allow-non-public-default-methods – shmosel

Я бы сказал, это дополнительные функции, на вершине того, что было раньше Java 8

Как вы сказали, его правильно - может быть по умолчанию и статический (доступный интерфейс только и не может быть перекрыты.)

От оракула, когда вы расширяете интерфейс, который содержит метод по умолчанию, вы можете сделать следующее

Не упоминайте метод по умолчанию, который позволяет расширенному интерфейсу наследовать метод по умолчанию.

Redeclare метод по умолчанию, который делает его абстрактным.

Переопределить метод по умолчанию, который переопределяет его.

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

Коллекции в java.utils использовали методы по умолчанию для поддержки лямбда-выражений. Теперь некоторые сценарии, где это может быть полезно.

в большом количестве приложения нам нужен базовый класс реализации, а затем мы продолжим этот класс ИЭ BaseImplClass implements IsomeInterface Таким образом, вместо того, чтобы иметь BaseImplClass, у вас есть возможность определения реализации этих значений по умолчанию в интерфейсе, который может быть overrriden если необходимо.
Если у вас есть какие-либо вспомогательные или служебные классы, вы можете использовать статические методы в интерфейсе ... которые являются открытыми, окончательными и не могут быть переопределены

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

источник

2016-02-14 19:32:26 surya

* «Во многих приложениях нам нужен базовый класс реализации ... Поэтому вместо того, чтобы иметь BaseImplClass, у вас есть возможность определить эту реализацию по умолчанию в вашем интерфейсе» * ... Я хотел бы указать, что скелетные, базовые или абстрактные реализации интерфейсов остаются полезной конструкцией. Вариант замены реализации скелета с помощью интерфейса с методами по умолчанию существует только в том случае, если реализация может быть выполнена с использованием только вызовов методов интерфейса. Если требуется состояние, тогда абстрактный класс по-прежнему обычно является правильным. – scottb

Ответ1 : Я убежден, что методы по умолчанию обеспечивают частичное инкапсулирование. Потому что когда-либо мы обертываем код внутри класса (теперь возможно внутри интерфейса), там есть инкапсуляция. В первую очередь это современный подход абстракции, где мы можем обеспечить то, что хотим, вместо того, как мы хотим это сделать.

Ответ2: Это не новая проблема, новички могут сделать много опасности, чем это. Я думаю, что мы можем настроить check-style, чтобы не допускать таких методов.

источник

2016-05-31 14:37:18

* «Я убежден, что методы по умолчанию обеспечивают частичную инкапсуляцию. Потому что когда-бы мы обертываем код внутри класса (теперь возможно внутри интерфейса), существует инкапсуляция. В первую очередь это современный подход абстракции, где мы можем предоставить то, что хотим а не как мы хотим это сделать ». * ... Я совершенно уверен, что понятия не имею, что это значит. – scottb

В Java 8 интерфейс нарушает концепцию инкапсуляции?

ответ

Смежные вопросы