Як я можу здійснити дзвінок із булевим ясним? Булева пастка

Як зазначається у коментарях @ benjamin-gruenbaum, це називається булевою пасткою:

Скажіть, у мене така функція

UpdateRow(var item, bool externalCall);

і в моєму контролері це значення для externalCallзавжди буде ПРАВИЛЬНИМ. Який найкращий спосіб викликати цю функцію? Я зазвичай пишу

UpdateRow(item, true);

Але я запитую себе, чи повинен я оголосити булеве, аби лише вказати, на що означає «справжнє» значення? Ви можете це знати, переглянувши декларацію функції, але це, очевидно, швидше і зрозуміліше, якщо ви просто побачили щось подібне

bool externalCall = true;
UpdateRow(item, externalCall);

ПД: Не впевнений, чи справді це питання тут підходить, якщо воно не відповідає, де я можу отримати більше інформації про це?

PD2: Я не тегував жодної мови, тому що думав, що це дуже загальна проблема. У будь-якому випадку я працюю з c # і прийнята відповідь працює для c #

Не завжди є ідеальним рішенням, але у вас є багато альтернатив:

• Використовуйте названі аргументи , якщо вони доступні вашою мовою. Це працює дуже добре і не має особливих недоліків. У деяких мовах будь-який аргумент може бути переданий як іменований аргумент, наприклад updateRow(item, externalCall: true)( C # ) або update_row(item, external_call=True)(Python).

  Ваша пропозиція використовувати окрему змінну - це один із способів моделювання названих аргументів, але не має відповідних переваг для безпеки (немає гарантії, що ви використовували правильну назву змінної для цього аргументу).

• Використовуйте різні функції для вашого публічного інтерфейсу з кращими назвами. Це ще один спосіб моделювання названих параметрів шляхом введення значень параметрів у назві.

  Це дуже легко читається, але призводить до того, що ви багато пишете ці функції. Він також не може добре впоратися з комбінаторним вибухом, коли є декілька булевих аргументів. Суттєвим недоліком є ​​те, що клієнти не можуть динамічно встановлювати це значення, але повинні використовувати if / else для виклику правильної функції.

• Використовуйте перерахунок . Проблема з булевими полягає в тому, що їх називають "справжніми" та "помилковими". Отже, замість цього введіть тип із кращими іменами (наприклад enum CallType { INTERNAL, EXTERNAL }). Як додаткова перевага, це підвищує безпеку типу вашої програми (якщо ваша мова реалізує перераховує як окремі типи). Недолік переліків полягає в тому, що вони додають тип вашому загальнодоступному API. Для суто внутрішніх функцій це не має значення, і перерахунки не мають суттєвих недоліків.

  У мовах без перерахунків іноді використовують короткі рядки . Це працює, і може бути навіть краще, ніж сирі булеви, але дуже чутливі до помилок. Потім функція повинна негайно стверджувати, що аргумент відповідає набору можливих значень.

Жодне з цих рішень не має надмірного впливу на продуктивність. Іменовані параметри та перерахунки можуть бути повністю вирішені під час компіляції (для компільованої мови). Використання рядків може включати порівняння рядків, але вартість цього незначна для невеликих літеральних рядків і більшості видів програм.

Правильне рішення - робити те, що ви пропонуєте, але упакуйте його в міні-фасад:

void updateRowExternally() {
  bool externalCall = true;
  UpdateRow(item, externalCall);
}

Читальність козирує мікрооптимізацію. Ви можете дозволити собі додатковий виклик функції, безумовно, краще, ніж ви можете дозволити розробнику зусиль, що потрібно ще раз переглянути семантику булевого прапора.

Скажіть, у мене є така функція, як UpdateRow (var item, bool externalCall);

Чому у вас така функція?

За яких обставин ви б назвали це аргументом externalCall, встановленим на різні значення?

Якщо один із, скажімо, зовнішніх, клієнтських додатків, а інший знаходиться в межах однієї програми (тобто різних модулів коду), то я б заперечував, що у вас повинні бути два різних методу, один для кожного випадку, можливо, навіть визначений на різних Інтерфейси.

Якщо ж ви здійснювали виклик на основі якогось даного даних, взятого з непрограмного джерела (скажімо, зчитували файл конфігурації чи базу даних), то метод булевої передачі мав би більше сенсу.

Хоча я згоден, ідеально використовувати мовну функцію для забезпечення читабельності та безпеки цінності, ви також можете скористатися практичним підходом: коментарі під час дзвінка. Подібно до:

UpdateRow(item, true /* row is an external call */);

або:

UpdateRow(item, true); // true means call is external

або (правильно, як це запропонував Frax):

UpdateRow(item, /* externalCall */true);

1. Ви можете «назвати» ваші булі. Нижче наводиться приклад мови OO (де вона може бути виражена класом, що надає UpdateRow()), проте сама концепція може бути застосована будь-якою мовою:

   class Table
   {
   public:
       static const bool WithExternalCall = true;
       static const bool WithoutExternalCall = false;
   

   та на сайті виклику:

   UpdateRow(item, Table::WithExternalCall);
   

2. Я вважаю, що пункт 1 є кращим, але він не змушує користувача використовувати нові змінні під час використання функції. Якщо безпека типу важлива для вас, ви можете створити enumтип і змусити UpdateRow()прийняти це замість bool:

   UpdateRow(var item, ExternalCallAvailability ec);

3. Ви можете якось змінити ім'я функції, щоб воно краще відображало значення boolпараметра. Не дуже впевнений, але можливо:

   UpdateRowWithExternalCall(var item, bool externalCall)

Ще один варіант, якого я тут ще не читав: Використовуйте сучасний IDE.

Наприклад, IntelliJ IDEA друкує ім'я змінної змінних у методі, який ви викликаєте, якщо ви передаєте літерал, такий як trueабо nullабо username + “@company.com. Це робиться невеликим шрифтом, щоб він не займав занадто багато місця на екрані і виглядав дуже відмінним від фактичного коду.

Я все ще не кажу, що гарну ідею скрізь кидати буліни. Аргумент, який говорить про те, що ви читаєте код набагато частіше, ніж ви пишете, часто дуже сильний, але для цього конкретного випадку це сильно залежить від технології, яку ви (та ваші колеги!) Використовуєте для підтримки своєї роботи. З IDE це набагато менше проблем, ніж, наприклад, vim.

Модифікований приклад частини моєї тестової установки:

2 дні і ніхто не згадав про поліморфізм?

target.UpdateRow(item);

Коли я клієнт, який хоче оновити рядок із елементом, я не хочу думати про назву бази даних, URL-адресу мікро-сервісу, протокол, який використовується для зв'язку, чи незалежний зовнішній виклик потрібно буде використовувати, щоб це сталося. Перестань тискати на мене ці деталі. Просто візьміть мій товар і перейдіть оновити рядок вже кудись.

Зробіть це, і це стане частиною будівельної проблеми. Це можна вирішити багатьма способами. Ось один:

Target xyzTargetFactory(TargetBuilder targetBuilder) {
    return targetBuilder
        .connectionString("some connection string")
        .table("table_name")
        .external()
        .build()
    ; 
}

Якщо ви дивитесь на це і думаєте: "Але моя мова назвала аргументи, мені це не потрібно". Чудово, чудово, ідіть, використовуйте їх. Просто тримайте цю нісенітницю від клієнта, який дзвонить, який навіть не повинен знати про що він говорить.

Слід зазначити, що це більше, ніж семантична проблема. Це також проблема дизайну. Пройдіть булевим, і ви змушені використовувати розгалуження для боротьби з ним. Не дуже об’єктно орієнтована. У вас є два або більше буленів? Бажаючи, щоб ваша мова мала кілька разів? Подивіться, що можуть робити колекції, коли ви розміщуєте їх. Правильна структура даних може значно полегшити ваше життя.

Якщо ви можете змінити updateRowфункцію, можливо, ви можете змінити її на дві функції. Зважаючи на те, що функція приймає булевий параметр, я підозрюю, що це виглядає приблизно так:

function updateRow(var item, bool externalCall) {
  Database.update(item);

  if (externalCall) {
    Service.call();
  }
}

Це може бути трохи кодовим запахом. Функція може мати різно різну поведінку залежно від того, для якої externalCallзмінної встановлено, і в цьому випадку вона має дві різні обов'язки. Повторний розподіл його на дві функції, на які покладено лише одну відповідальність, може покращити читабельність:

function updateRowAndService(var item) {
  updateRow(item);
  Service.call();
}

function updateRow(var item) {
  Database.update(item);
}

Тепер, де б ви не викликали ці функції, ви можете з першого погляду визначити, чи викликається зовнішня служба.

Звичайно, це не завжди так. Це ситуативно і справа смаку. Рефакторинг функції, яка бере булевий параметр на дві функції, зазвичай варто розглянути, але це не завжди найкращий вибір.

Якщо UpdateRow знаходиться в контрольованій базі коду, я б розглядав шаблон стратегії:

public delegate void Request(string query);    
public void UpdateRow(Item item, Request request);

Де Запит представляє якусь DAO (зворотний виклик у тривіальному випадку).

Справжній випадок:

UpdateRow(item, query =>  queryDatabase(query) ); // perform remote call

Неправдивий випадок:

UpdateRow(item, query => readLocalCache(query) ); // skip remote call

Зазвичай реалізація кінцевих точок буде налаштована на більш високому рівні абстракції, і я просто використовую її тут. Як корисний безкоштовний побічний ефект, це дає мені можливість реалізувати інший спосіб доступу до віддалених даних без будь-яких змін до коду:

UpdateRow(item, query => {
  var data = readLocalCache(query);
  if (data == null) {
    data = queryDatabase(query);
  }
  return data;
} );

Взагалі така інверсія управління забезпечує меншу зв’язок між вашим сховищем даних та моделлю.