Як редагувати ланцюжок if-else, якщо заяви відповідають принципам чистого кодексу дядька Боба?

Я намагаюсь дотримуватися чистих пропозицій дядька Боба щодо коду та конкретно, щоб не допустити коротких методів.

Я не можу скоротити цю логіку:

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

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

Навіть семантично кажучи, оцінювати наступну умову, якщо попередня була виконана, з точки зору бізнесу не має сенсу.

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

Я вважаю, що це вже інше питання (це можна побачити також, порівнюючи відповіді на ці запитання).

• Моє запитання - перевірка, щоб перша умова прийняття швидко закінчилася .
• Зв'язане питання намагається створити всі умови, щоб прийняти , щоб зробити щось. (краще видно в цій відповіді на це питання: https://softwareengineering.stackexchange.com/a/122625/96955 )

В ідеалі, я думаю, ви повинні отримати свою логіку для отримання коду / номера попередження у свій метод. Тож ваш існуючий код зменшується аж до

{
    addAlert(GetConditionCode());
}

і у вас є GetConditionCode () інкапсуляція логіки для перевірки умов. Можливо, також краще використовувати Enum, ніж магічне число.

private AlertCode GetConditionCode() {
    if (CheckCondition1()) return AlertCode.OnFire;
    if (CheckCondition2()) return AlertCode.PlagueOfBees;
    if (CheckCondition3()) return AlertCode.Godzilla;
    if (CheckCondition4()) return AlertCode.ZombieSharkNado;
    return AlertCode.None;
}

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

Будь-яка спроба подальшого "спрощення" дійсно ускладнить справи.

Звичайно, ви можете замінити elseключове слово на таке, returnяк запропонували інші, але це лише питання стилю, а не зміна складності.

Убік:

Моя загальна порада: ніколи не слід релігійно ставитись до будь-якого правила щодо чистого коду: Більшість порад щодо кодування, які ви бачите в Інтернеті, є добрими, якщо його застосовують у відповідних умовах, але радикальне застосування цих же порад скрізь може виграти вам запис IOCCC . Хитрість завжди полягає в тому, щоб досягти балансу, який дозволяє людям легко міркувати про ваш код.

Використовуйте занадто великі методи, і вас накрутили. Використовуйте занадто малі функції, і ви накрутили. Уникайте потрійних виразів, і вас накрутили. Використовуйте потрійні вирази скрізь, і ви накрутили. Зрозумійте, що є місця, які викликають однолінійні функції, і місця, що вимагають 50-лінійних функцій (так, вони існують!). Зрозумійте, що є місця, які вимагають if()заяви, і що є місця, які вимагають ?:оператора. Використовуйте повний арсенал, який у вас є, і намагайтеся завжди використовувати найпридатніший інструмент, який ви зможете знайти. І пам’ятайте, не будьте релігійними навіть щодо цієї поради.

Це суперечливо, чи це "краще", ніж звичайна річ, якщо ... будь-який для даного випадку. Але якщо ви хочете спробувати щось інше, це звичайний спосіб зробити це.

Поставте свої умови в об’єкти і поставте їх у список

foreach(var condition in Conditions.OrderBy(i=>i.OrderToRunIn))
{
    if(condition.EvaluatesToTrue())
    {
        addAlert(condition.Alert);
        break;
    }
}

Якщо потрібно кілька дій, за умови, що ви можете зробити кілька шалених рекурсій

void RunConditionalAction(ConditionalActionSet conditions)
{
    foreach(var condition in conditions.OrderBy(i=>i.OrderToRunIn))
    {
        if(condition.EvaluatesToTrue())
        {
            RunConditionalAction(condition);
            break;
        }
    }
}

Очевидно, що так. Це працює лише в тому випадку, якщо ви маєте зразок своєї логіки. Якщо ви спробуєте зробити надзагальну рекурсивну умовну дію, налаштування для об'єкта буде настільки ж складною, як і початковий оператор if. Ви винайдете свою власну нову мову / рамку.

Але ваш приклад дійсно є шаблон

Поширеним випадком використання цього шаблону буде валідація. Замість :

bool IsValid()
{
    if(condition1 == false)
    {
        throw new ValidationException("condition1 is wrong!");
    }
    elseif(condition2 == false)
    {
    ....

}

Стає

[MustHaveCondition1]
[MustHaveCondition2]
public myObject()
{
    [MustMatchRegExCondition("xyz")]
    public string myProperty {get;set;}
    public bool IsValid()
    {
        conditions = getConditionsFromReflection()
        //loop through conditions
    }
}

Подумайте про використання return;після того, як одна умова була успішною, це заощадить всі ви else. Ви навіть можете мати можливість return addAlert(1)безпосередньо, якщо цей метод має повернене значення.

Я бачив подібні конструкції, які вважаються чистішими:

switch(true) {
    case cond1(): 
        statement1; break;
    case cond2():
        statement2; break;
    case cond3():
        statement3; break;
    // .. etc
}

Тернар з правильним інтервалом також може бути акуратною альтернативою:

cond1() ? statement1 :
cond2() ? statement2 :
cond3() ? statement3 : (null);

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

Як варіант відповіді @ Евана, ви можете створити ланцюжок (замість "плоского списку") таких умов:

abstract class Condition {
  private static final  Condition LAST = new Condition(){
     public void alertOrPropagate(DisplayInterface display){
        // do nothing;
     }
  }
  private Condition next = Last;

  public Condition setNext(Condition next){
    this.next = next;
    return this; // fluent API
  }

  public void alertOrPropagate(DisplayInterface display){
     if(isConditionMeet()){
         display.alert(getMessage());
     } else {
       next.alertOrPropagate(display);
     }
  }
  protected abstract boolean isConditionMeet();
  protected abstract String getMessage();  
}

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

Саме тут він переважає над підходом "плоского списку", коли вам потрібно здійснити "пропуск" у циклі, який застосовує умови.

Ви просто налаштуєте ланцюг умов:

Condition c1 = new Condition1().setNext(
  new Condition2().setNext(
   new Condition3()
 )
);

І почніть оцінювання з простого дзвінка:

c1.alertOrPropagate(display);

Перш за все, оригінальний код не страшний IMO. Це досить зрозуміло, і в ньому немає нічого поганого.

Тоді якщо вам це не подобається, вибудовуючи ідею @ Евана використовувати список, але видаляючи його дещо неприродний foreach breakзразок:

public class conditions
{
    private List<Condition> cList;
    private int position;

    public Condition Head
    {
        get { return cList[position];}
    }

    public bool Next()
    {
        return (position++ < cList.Count);
    }
}


while not conditions.head.check() {
  conditions.next()
}
conditions.head.alert()

Тепер адаптуйте це на своїй обраній мові, зробіть кожен елемент списку предметом, кортежем, будь-яким, і ви добре.

EDIT: схоже, це не так зрозуміло, як я думав, тому дозвольте мені пояснити далі. conditions- упорядкований список якогось роду; head- це поточний елемент, який досліджується - на початку це перший елемент списку, і щоразу, коли next()він називається, він стає наступним; check()і alert()є checkConditionX()та addAlert(X)з ОП.

У питанні відсутня певна специфіка. Якщо умови такі:

• підлягає зміні або
• повторюється в інших частинах програми або системи або
• модифіковані в певних випадках (наприклад, різні збірки, тестування, розгортання)

або якщо вміст у addAlertскладніший, можливим кращим рішенням у скажімо c # буде:

//in some central spot
IEnumerable<Tuple<Func<bool>, int>> Conditions = new ... {
  Tuple.Create(CheckCondition1, 1),
  Tuple.Create(CheckCondition2, 2),
  ...
}

//at the original place
var matchingCondition = Conditions.Where(c=>c.Item1()).FirstOrDefault();
if(matchingCondition != null) 
  addAlert(matchingCondition.Item2)

Кортежі не такі гарні в c # <8, але вибрані для зручності.

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

Найкращий спосіб зменшити складність цикломатики у випадках, коли вас багато, if->then statements- використовувати словник або список (залежно від мови) для зберігання ключового значення (якщо значення заяви або деяке значення), а потім значення / функція.

Наприклад, замість (C #):

if (i > 10) { return "Two"; }
else if (i > 8) { return "Four" }
else if (i > 4) { return "Eight" }
return "Ten";  //etc etc say anything after 3 or 4 values

Я можу просто

var results = new Dictionary<int, string>
{
  { 10, "Two" },
  { 8, "Four"},
  { 4, "Eight"},
  { 0, "Ten"},
}

foreach(var key in results.Keys)
{
  if (i > results[key]) return results.Values[key];
}

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

var results = new Dictionary<Func<int, bool>, Func<int, string>>
{
  { (i) => return i > 10; ,
    (i) => return i.ToString() },
  // etc
};

foreach(var key in results.Keys)
{ 
  if (key(i)) return results.Values[key](i);
}

Я намагаюсь дотримуватися чистих пропозицій дядька Боба щодо коду та конкретно, щоб не допустити коротких методів.

Я не можу скоротити цю логіку:

if (checkCondition()) {addAlert(1);}
else if (checkCondition2()) {addAlert(2);}
else if (checkCondition3()) {addAlert(3);}
else if (checkCondition4()) {addAlert(4);}

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

if (is_an_apple()) {
  addAlert(1);
}
else if (is_a_banana()) {
  addAlert(2);
}
else if (is_a_cat()) {
  addAlert(3);
}
else if (is_a_dog()) {
  addAlert(4);
}

Ваш код повинен бути читабельним понад усе. Прочитавши кілька книг дядька Боба, я вважаю, що це повідомлення, яке він постійно намагається натрапити.

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

EG: checkCondition1()стане evaluateCondition1(), на якому він буде перевіряти, чи було виконано попередню умову; якщо так, то воно кешує якесь значення, яке слід отримати getConditionNumber().

checkCondition2()стане evaluateCondition2(), на якому він би перевірив, чи були виконані попередні умови. Якщо попередня умова не була виконана, вона перевіряє сценарій умови 2, кешуючи значення, яке слід отримати getConditionNumber(). І так далі.

clearConditions();
evaluateCondition1();
evaluateCondition2();
evaluateCondition3();
evaluateCondition4();
if (anyCondition()) { addAlert(getConditionNumber()); }

Редагувати:

Ось як потрібно перевірити дорогі умови для здійснення цього підходу.

bool evaluateCondition34() {
    if (!anyCondition() && A && B && C) {
        conditionNumber = 5693;
        return true;
    }
    return false;
}

...

bool evaluateCondition76() {
    if (!anyCondition() && !B && C && D) {
        conditionNumber = 7658;
        return true;
    }
    return false;
}

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

clearConditions();
evaluateCondition10();
evaluateCondition9();
evaluateCondition8();
evaluateCondition7();
...
evaluateCondition34();
...
evaluateCondition76();

if (anyCondition()) { addAlert(getConditionNumber()); }

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

Будь-яке більше двох "інших" пропозицій змушує читача коду пройти через увесь ланцюг, щоб знайти цікавий. Використовуйте такий метод, як: void AlertUponCondition (умова умови) {switch (condition) {case Condition.Con1: ... break; випадок Умова.Кон2: ... перерва; тощо ...} Де "Умова" є належним перерахуванням. Якщо потрібно, поверніть булінг або значення. Назвіть це так: AlertOnCondition (GetCondition ());

Це дійсно не може бути простішим, І це швидше, ніж ланцюг if-else, коли ви перевищите кілька випадків.

Я не можу говорити для вашої конкретної ситуації, оскільки код не конкретний, але ...

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

Поліморфізм, можливо, вам більше підходить.

Будьте підозрілі до коду з довгими методами, що містять довгі або складні конструкції if-then. Ви часто хочете, щоб там було класне дерево за допомогою деяких віртуальних методів.