Что такое «клиент» в принципе разделения интерфейсов (ISP)?

Question

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

В этом случае у меня есть вопрос о «принципе разделения интерфейса» (ISP) из пяти «SOLID» принципов базового объектно-ориентированного проектирования. Его «каноническое» утверждение таково:

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

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

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

Во-первых, если что-то используется в достаточном количестве мест, это особенно последнее - "вызывающий" - который обычно имеет тенденцию "кусаться", поскольку это естественным образом приводит к тому, что ваши интерфейсы распыляются только до отдельных методов. Например, рассмотрим простой интерфейс к внутреннему хранилищу или базе данных, который может иметь , , а также метод. Однако некоторые из тех, кто это делает, могут не захотеть ничего сохранять. Они могут просто захотеть взглянуть на данные. Следовательно, чтобы избежать нарушения интерпретации вызывающей стороны, мы должны отделить метод загрузки. Добавьте еще несколько вариантов использования, и теперь он разбит на , , а также у всех есть 1 метод каждый.

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