Должны ли имена методов в интерфейсах быть конкретными или абстрактными?

Question

Часто, когда я создаю новые классы, я сначала создаю новый интерфейс.Я называю методы моего интерфейса точно так, как я хотел бы, чтобы они вели себя.Мой коллега предпочитает, чтобы эти имена методов были более абстрактными, а именно: areConditionsMet ().Причина, он хочет скрыть «детали реализации».

Детали реализации IMO отличаются от ожидаемого поведения.Может ли кто-нибудь дать больше понимания.Моя цель - найти общий язык с коллегой.

Answer 1

Ваши имена методов должны описывать, что метод делает, но не как он это делает. В качестве примера вы привели довольно плохое имя метода, но оно лучше, чем isXGreatherThan1AndLessThan6(). Не зная подробностей о том, что он должен делать, я бы сказал, что он должен быть специфичным для рассматриваемой проблемы, но достаточно общим, чтобы реализация могла измениться, не затрагивая само имя, т. Е. Вам не нужно имя метода быть хрупким Примером может быть isTemperatureWithinRange() - он описывает то, что я проверяю, но не описывает, как это делается. Пользователь метода должен быть уверен, что результат будет отражать, находится ли температура в определенном диапазоне - независимо от того, указывается ли это в качестве аргумента или определяется контрактом класса, несущественно.

Answer 2

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

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

Однако по вашему вопросу трудно сказать, каков точный случай.

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

Answer 3

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

На основании ваших обновленных комментариев:

Похоже, вам нужны два метода: isModified () и hasProperties () * * +1010.Оставьте это на усмотрение пользователя (или более высокого уровня) объекта домена, чтобы определить, удовлетворяется ли конкретный критерий.

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