Походження "методу має повернути значення або мати побічні ефекти, але не обидва"

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

Яке походження цієї поради? З якої людини чи громади вона виникла?

Додатковий кредит: Яка заявлена ​​вигода від використання цієї поради?

За словами Грега Янг, ця ідея виникла з Бертрана Мейєра : відділення команд-запитів .

У ньому зазначається, що кожен метод повинен бути або командою, яка виконує дію, або запитом, який повертає дані абоненту, але не обидва. Іншими словами, запитання не повинно змінювати відповідь . ¹ Більш формально, методи повинні повертати значення лише в тому випадку, якщо вони є відносно прозорими і, отже, не мають побічних ефектів.

1: Ейфель: мова для слайдів 43-48 інженерії програмного забезпечення

У дизайні, керованому доменом, це схоже на розділення / сегрегація читання команд-запитів, що читаються (CQRS), як назвав Грег Янг.

Грег Янг взяв ідею CQS від Бертран назвати CQRS, як згадував Мартін Фаулер у цій статті про CQRS

Переваги

• Частина читання (запиту) може бути масштабована / налаштована інакше, ніж частина запису (команди). Розмежування обох завадить не заважати один одному, коли ключова оптимізація / продуктивність.

Докладніше читайте статтю у посиланні Мартіна Фаулера .

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

Будь-яка грамотно розроблена програма буде розбита на різні частини, поєднана та складена різними способами. Чим складніше міркувати про те, що робить якась конкретна частина, тим важче буде переконатися, що ваша програма буде реагувати передбачувано.

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

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

Додатковий кредит: Яка спочатку заявлена вигода від дотримання цієї поради?

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

bool FooWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

bool BarWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

void BadShortCircuitEvaluation()
{
    // the programmer's intent is to have side effects of both functions
    if (FooWithSideEffect() && BarWithSideEffect() ) {
        // do something
    }

    // in case FooWithSideEffect() returns true, 
    // then BarWithSideEffect() is not called at all
    // because of short-circuit evaluation
}