TL; DR: не використовуйте булеві аргументи.
Нижче дивіться, чому вони погані, і як їх замінити (жирним обличчям).
Булеві аргументи дуже важко читати, а значить, важко підтримувати. Основна проблема полягає в тому, що мета, як правило, зрозуміла, коли ви читаєте підпис методу, де аргументовано ім'я. Однак іменування параметра, як правило, не потрібно в більшості мов. Таким чином, у вас з'являться анти-шаблони, наприклад, RSACryptoServiceProvider#encrypt(Byte[], Boolean)де булевий параметр визначає, який тип шифрування повинен бути використаний у функції.
Тож ви отримаєте дзвінок на зразок:
rsaProvider.encrypt(data, true);
де читач повинен шукати підпис методу, щоб просто визначити, що пекло trueнасправді може означати. Проходження цілого числа, звичайно, так само погано:
rsaProvider.encrypt(data, 1);
сказала б вам так само - а точніше: так само мало. Навіть якщо ви визначаєте константи, які будуть використовуватися для цілого числа, користувачі функції можуть просто ігнорувати їх і продовжувати використовувати буквальні значення.
Найкращий спосіб вирішити це - використовувати перерахування . Якщо вам доведеться передати enum RSAPaddingз двома значеннями: OAEPабо PKCS1_V1_5тоді ви відразу зможете прочитати код:
rsaProvider.encrypt(data, RSAPadding.OAEP);
Булеви можуть мати лише два значення. Це означає, що якщо у вас є третій варіант, вам доведеться переробляти підпис. Як правило, це не може бути легко виконано, якщо сумісність ззаду є проблемою, тому вам доведеться поширити будь-який публічний клас іншим публічним методом. Це те, що нарешті зробило Microsoft, коли вони представили, RSACryptoServiceProvider#encrypt(Byte[], RSAEncryptionPadding)де вони використовували перерахування (або принаймні клас, що імітує перерахування) замість булевого.
Можливо, навіть простіше використовувати повноцінний об'єкт або інтерфейс як параметр, якщо сам параметр потребує параметризації. У вищенаведеному прикладі прокладка OAEP сама може бути параметризована хеш-значенням для внутрішнього використання. Зауважте, що зараз існує 6 хеш-алгоритмів SHA-2 та 4 хеш-алгоритми SHA-3, тому кількість значень перерахування може вибухнути, якщо ви використовуєте лише одне перерахування, а не параметри (це, можливо, наступне, що Microsoft збирається з'ясувати) ).
Булеві параметри також можуть вказувати на те, що метод або клас не розроблені належним чином. Як і у наведеному вище прикладі: будь-яка криптографічна бібліотека, окрім .NET, взагалі не використовує прапор для замітки у підписі методу.
Практично всі програмні гуру, які мені подобаються, застерігають від бульних аргументів. Наприклад, Джошуа Блох застерігає від них у високо оціненій книзі "Ефективна Java". Взагалі їх просто не слід використовувати. Ви можете стверджувати, що вони можуть бути використані, якщо є один параметр, який легко зрозуміти. Але навіть тоді: Bit.set(boolean)мабуть, краще реалізуватися за допомогою двох методів : Bit.set()і Bit.unset().
Якщо ви не можете безпосередньо переробити код, ви можете визначити константи, щоб принаймні зробити їх більш зрозумілими:
const boolean ENCRYPT = true;
const boolean DECRYPT = false;
...
cipher.init(key, ENCRYPT);
набагато читає, ніж:
cipher.init(key, true);
навіть якщо ви хочете:
cipher.initForEncryption(key);
cipher.initForDecryption(key);
замість цього.