Аргументы-флаги¶
В главе “Flag Arguments” известной книги «Clean Code. A Handbook of Agile Software Craftsmanship.», Robert C. Martin советует не использовать аргументов-флагов, справедливо замечая, что это свидетельствует о том, что функция делает более одной операции.
Но что если функция, например, атомарно создает неизменяемый объект? Если состояние объекта зависит от 5-ти флагов, то для того, чтобы разбить функцию на безфлаговые нам придется создать 2^5 = 32 фиксированные функции чтобы перебрать все возможные комбинации флагов.
Это приводит нас к одной из мотиваций паттерна “Bridge” - устранению комбинаторного роста количества классов. Чтобы не создавать иерархию классов для каждой реализации (раздувая количество классов), применяется композиция вместо наследования. Иначе говоря, речь идет о превосходстве композиции перед наследованием.
В данном случае, чтобы не создавать комбинаторного роста количества функций, могут быть использованы флаги. Robert C. Martin эту тему не раскрыл, а жаль.
В качестве иллюстрации можно привести битовые маски флагов функций re.search(pattern, string, flags=0) или open(name[, mode[, buffering]]). Только представьте себе, сколько понадобилось бы функций, чтобы выразить все возможные сочетания флагов.