Comments 10
Что-то мне говорит, что фанатичное следование (а джависты по-другому не могут) этим советам приведет к большим проблемам, чем представляют из себя три параметра в функции.
Полиморфизм вместо булевого параметра (по-хорошему, необходимо просто разделить метод на два, и if переместить из этой в функции в функцию, где эти две разные функции вызываются, заодно и параметр исчезнет) приведет к умножению ненужных классов и к сложности.
Сайд-эффекты неизбежны. На то он и класс с методами, что вызов методов меняет состояние объекта класса. Методы, не меняющие состояние объекта, вырождают ООП до состояния наборов функций и структур, то есть процедурное программирование. Хотя, иммутабельность во многих случаях полезно применять, но джависты не умеют без фанатизма.
Методы, не меняющие состояние объекта, вырождают ООП до состояния наборов функций и структур, то есть процедурное программирование
Да, вырождают. И nobody cares. Потому что все промышленные языки давно уже мультипарадигменные. Где удобно - применяешь ООП, где удобно - ПП или ФП.
Судя по тому, что вы говорите про джавистов на "вы" - то не программируете на нем. Джависты ой как по другому могут))
Сайд эффекты неизбежны - это факт
Не используйте nullable-аргументы
Не согласен. Вполне нормальная практика, когда значение NULL у nullable-аргумента означает, что функция работает со значением по умолчанию.
А как функция выглядит внутри? Если она обрабатывает null как отдельный случай - на мой взгляд это плохо. Если внутри применен, например, NullObjectPattern - то наверно норм
Да примерно так:
function foo(buz, biz) {
if (buz == null) {
buz = defaultValue;
}
}
foo(null, 5);В принципе, для языков, где нельзя задать значение аргумента по умолчанию и нет именованных аргументов, это вполне допустимое решение.
Я бы использовал для аргументов по умолчанию перегрузку методов
Опять же, не везде она есть. И как перегружать метод, если в нем два аргумента с одинаковым типом, и у обоих есть значения по умолчанию?
foo(buz, biz);
foo(buz);
foo(null, biz);
foo();
Я воспринимаю чистый код как отличную практику, к которой надо стремиться, но не как догму. Если у меня не получается написать с соблюдением правил - я довольствуюсь тем, что покрыл код тестами хорошо (написав его через TDD) и в дальнейшем если у меня или у кого-то появится идея как отрефакторить - он сделает это безопасно
Любит дядюшка Боб кинуть пыль в глаза, обожаю его, весёлый мужик.
Количество аргументов функции - тут главное не загнать себя в ловушку, именованные параметры есть не только в kotlin, но и c# или php. Аргумент про то, что связанные параметры должны быть классом, справедлив, если эти совместно изменяются и потом, как только мы их сделали классом, теперь они летят большой кучей в конструктор. Как по мне много параметров ни есть проблема, как минимум в конструкторе.
Передача булевых аргументов - есть кейсы когда мы просто хотим засетить флаг, но передавать bool как режим работы - страшное дело.
Не используйте возвращаемые аргументы - вообще вроде бы такой код являет процедурой. Менять аргументы функции не умеют, за то умеют принимать ссылки на ресурс (указатели, хосты, имена файлов и т.д.) и дальше по ним изменять этот ресурс. Не подходит для ООП, но полностью от процедур не уйти, надо знать где применять.
Не используйте nullable-аргументы - наверно справедливо только для языков где nullable не указать в типе.
Stepdown rule - лучше просто не использовать приватные функции :) и перетащить всё в отдельный класс. На крайний случай в самый низ.
Switch case - в целом да. Но есть ряд исключений и как по мне дело даже е в ООП.
От пользователя приходит 10 видов запросов, надо их как-то роутить, например.
Не все классы можно подогнать под общий интерфейс, можно иметь два абсолютно разных класса, и абсолютно по разному их нужно обработать.
Side-эффекты - практически всё ООП на них строиться :)
CQS проблему не решить, а только перенести на уровень выше.
Решается проблема тестами.
К слову, query не имеющие сайдов, отличаются от чистых функций, отвечающих всегда одинаково на один и тот же запрос.
Чистый код. Часть 2