Использование одного метода с константами в качестве параметров вместо нескольких методов

Question

В шаблонах реализации Кента Бека можно прочитать

"Обычное использование констант заключается в сообщать варианты сообщения в интерфейс. Например, к центру текст, который вы могли бы вызвать setJustification(Justification.CENTERED). Одним из преимуществ этого стиля API является что вы можете добавить новые варианты существующие методы, добавляя новые константы без разрыва реализаторы. Тем не менее, эти сообщения не общайся так же как имея отдельный метод для каждого варианта. В этот стиль, сообщение выше будет justifyCentered(). Интерфейс, где все вызовы метода имеют буквальные константы в качестве аргументов могут быть улучшено, давая ему отдельные методы для каждого постоянного значения. "

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

void justifyRight()
void justifyLeft()
void justifyCentered()

Как правило, я бы поступил прямо противоположно советам Кента, которые должны были бы сгруппировать его в

setJustification(Justification justification)

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

Спасибо

Answer 1

Методы доступа к файлам обычно имеют параметры, относящиеся к режиму чтения / записи, создавать ли несуществующие файлы, атрибуты безопасности, режимы блокировки и т. Д.Представьте себе количество методов, которые у вас были бы, если бы вы создали отдельный метод для каждой действительной комбинации параметров !

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

Однако я не поддерживаю эту практику.API должны быть хорошо разработаны и должны меняться как можно меньше .Кент Бек о нарушении API-изменений:

Одним из преимуществ [параметризованных методов] является то, что вы можете добавлять новые варианты существующих методов, добавляя новые константы, не нарушая реализации.

Его аргумент в пользу отдельных методов:

Однако [параметризованные методы] не общаются так же, как и имеют отдельный метод для каждого варианта.

Я не согласен,Параметры метода могут быть такими же удобочитаемыми.Особенно в сочетании с именованными параметрами, эта функция поддерживается несколькими языками.Кроме того, отдельные методы приведут к перегрому API.

Answer 2

Полагаю, это субъективно. Некоторые могут утверждать, что justifyLeft более понятен, чем оправдывает (Justification.LEFT). Свертывание всего этого в один метод может привести к более приятному API - меньше беспорядка - и режим может быть сохранен в переменной и просто передан в один метод setXY (с помощью различные методы для каждого, вам придется решить, какой из них вызывать в зависимости от значения вручную). Поэтому я обычно предпочитаю этот путь. Хотя обычно это просто:

void justify(Justification justification) {
    switch(justification) {
        Justification.RIGHT: this.justifyRight();
        Justification.LEFT: this.justifyLeft();
        Justification.CENTERED: this.justifyCenter();
    }
}

Конечно, это целесообразно, только когда все эти методы очень тесно связаны.