Принцип разделения интерфейса и методы по умолчанию в Java 8

Question

Согласно принципу разделения интерфейса

клиенты не должны быть вынуждены реализовать нежелательные методы интерфейса

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

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

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

Не нарушает ли это озабоченность разделением? Мысли?

Answer 1

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

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

Answer 2

Нет.

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

Выдержка из моего более подробного ответа здесь:

В стандартной библиотеке есть примеры хороших применений. defaultметоды. Один был бы java.util.function.Function с его и compose(...)методы....

Эти методы по умолчанию не нарушают ISP, поскольку классы, реализующие Functionнет необходимости вызывать или отменять их. Может быть много случаев использования, когда конкретные экземпляры Function никогда не имеют своих andThen(...)вызывается метод, но это нормально - вы не нарушаете работу ISP, предоставляя полезные, но несущественные функции, до тех пор, пока вы не обременяете все эти варианты использования, заставляя их что-то делать с ним. В случае с Function предоставление этих методов как абстрактных, а не по умолчанию будет нарушением ISP, поскольку все реализующие классы должны будут добавлять свои собственные реализации, даже если они знают, что это вряд ли когда-либо будет вызвано.

Answer 3

Интернет-провайдер будет нарушен, если вы намереваетесь это сделать. Вы можете разделить интерфейсы для выполнения только одной ответственности. Группа методов для определенной ответственности, скорее всего, будет следовать правилу 80-20. Вы можете предоставить реализации по умолчанию для 40-50% методов из 80% части. Эта часть 40-50% будет той, которая будет редко использоваться, и, следовательно, значения по умолчанию в порядке. Если интерфейс выполняет единственную ответственность, они редко будут слишком большими, и чаще всего они будут в ISP.

Answer 4

Цитата в ОП не совсем точна. Фактическое заявление интернет-провайдера:

Клиенты не должны зависеть от интерфейсов, которые они не используют.

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

Причина, по которой ISP, не в том, чтобы уберечь разработчиков от реализации дополнительных абстрактных методов. Это сделано для того, чтобы уберечь вызывающего эти методы от ненужных транзитивных зависимостей. Дополнительные методы интерфейса рискуют вызвать дополнительные зависимости (через объявление или реализацию). Клиент, который не использует эти методы, по-прежнему приобретает эти зависимости и становится связанным с клиентами, которые действительно используют эти методы, посредством изменений, которые эти клиенты вносят в интерфейс и его общую реализацию.

Применяя этот принцип к defaultметоды в Java 8, такой метод, безусловно, может нарушить ISP, добавив зависимости, которые требуются не всем клиентам. С другой стороны, также возможно (и предпочтительно), чтобыdefaultметод, чтобы не добавлять никаких зависимостей и никогда не изменять каким-либо образом, нарушающим работу клиентов.

В итоге, defaultметоды - это просто еще один инструмент. Их можно использовать, чтобы помочь вашему коду или навредить ему.