Какие стоит создавать интерфейсы?

Question

[random55]

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

пример:

interface IPerson
{
    public function move();
    public function eat();
    public function sleep();
    public function work();
}

или же

interface IMove
{
    public function move();
}

interface IEat
{
    public function eat();
}

interface ISleep
{
    public function sleep();
}

interface IWork
{
    public function work();
}

Первый подход ограничивает использование интерфейса некоторым модулем, ведь он описывает персону, а не черты поведения в отдельности. А если бы, допустим, в у нас был отдельный интерфейс IMove, то мы смогли бы реализовать его в каком угодно модуле/компоненте, например в условном File, ведь мы можем переместить файл. Так же и с ISleep, мало ли что может уснуть, начиная от операционной системы или потока выполнения, заканчивая персонажем в тамагочи.

Но смущает одно, IMove::move() для персонажа игры, скорее всего, будет принимать x,y координаты, а для файла - конечный путь.

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

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

Comments

[Александр Шипин]

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

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

Грубо, класс File при выполнении Move будет перемещаться из папки в папку, а класс Person при выполнении Move будет двигаться по координатам

Answer 1

[Михаил]

А если бы, допустим, в у нас был отдельный интерфейс IMove, то мы смогли бы реализовать его в каком угодно модуле/компоненте, например в условном File, ведь мы можем переместить файл. Так же и с ISleep, мало ли что может уснуть, начиная от операционной системы или потока выполнения, заканчивая персонажем в тамагочи.

Неверно. IMove (точнее будет назвать Movable) имеет смысл в контексте какой-то предметной области. И перемещение файла, перемещение спрайта, перемещение трехмерного объекта, перемещение руки робота - все это разные перемещения. Соответственно и интерфейсы будут разные (расположенные в разных модулях, даже если будут называться одинаково), например:

filesystem.Movable
graphics.2d.Movable
graphics.3d.Movable
servo.Movable

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

Вообще главный принцип тут такой: интерфейс должен иметь смысл, описывать некоторую единицу функциональности именно с точки зрения предметной области. Скажем, если в вашей предметной области операция move имеет смысл без операций eat и sleep - её можно выделить в отдельный интерфейс (а можно и не выделять, это зависит от других факторов). Если же операции eat и sleep всегда должны ходить парой и каждый потребитель этого интерфейса нуждается в обеих операциях - они должны быть в одном интерфейсе.

Comments

[random55]

А что делать в случае, если интерфейс описывает одну и ту же абстракцию, но сама абстракция подразумевает переменное число аргументов? Использовать массив или DTO? Или, может быть, убрать аргументы из сигнатуры метода, и подразумевать что они будут переданы в конструкторы классов, реализующих этот интерфейс (ведь конструктор будет у каждого свой)? Как вы решаете подобные проблемы?

[Михаил]

random55, давайте на вашем примере.

Переменное число однородных аргументов - это список или массив.
Необязательные аргументы - это все равно аргументы, просто они могут быть null (или использовать класс Optional и подобные - зависит от конкретного языка)

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

[Михаил]

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

Например:

interface Animation {
  fun move(from: Point, to: Point, duration: Duration)
}

class AnimationImpl(private val curve: Curve): Animation {
...
}

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

[random55]

Михаил, огромное спасибо! Вы не представляете как сильно помогаете мне уже третий вопрос подряд. Начинаю на порядок лучше понимать фундаментальные вещи.

Answer 2

[Alexandroppolus]

4 принцип SOLID предписывает создавать настолько маленькие, насколько возможно. При этом реализация может имплементировать несколько интерфейсов.

Но смущает одно, IMove::move() для персонажа игры, скорее всего, будет принимать x,y координаты, а для файла - конечный путь.

да. Это совершенно разные интерфейсы. Всё правильно.
Person заимплементит IMove с координатами, а File - с путем.