Довгий список параметрів проти списку змінних довгого стану

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

functional-programming object-oriented-design

— TomCaps
джерело

Чи була оригінальна книга, що коментує C ++, функціональною мовою?

— Мартін Йорк

Відповіді:

Залежить , якщо ви програмуєте в proceduralабо functionalпарадигмі. Стан, що змінюється, потрібен для колишнього, а калік для подальшого. Це яблука та апельсини. Вони обоє правильні у своїх судових справах!

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

:Дякую! У книзі << 97 речей, які повинен знати кожен програміст >>, ми повинні застосовувати принципи функціонального програмування, такі як уникнення побічної дії. Чи не можемо ми застосувати принципи функціонального програмування в контексті імперативного коду?

— TomCaps

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

— Мар'ян Венема

@Marjan все, що має незмінні змінні, є state

@Jarrod: Тепер ти розгубився. Читаючи Вашу відповідь ще раз, я бачу, що я пропустив "Змінний" у "Потрібно змінити стан". Але ваш коментар, схоже, говорить про те, що наявність незмінних змінних - це стан. Не зрозумійте. Це може бути тому, що я не звик кидатися і думати про змінне і незмінне в цих термінах. Будь-які посилання для мене для читання?

— Мар'ян Венема

@MarjanVenema: Так, незмінними змінними є стан. Різниця в режимі обробки між процедурним та функціональним програмуванням не в тому, що proc.prog. має стан, а функціонал - ні, швидше, різниця полягає в тому, що проц. прог. має змінний стан, тоді як стан завжди незмінний у (чистому) функціональному програмуванні. Див., Наприклад, en.wikipedia.org/wiki/Purely_functional , де пояснюється, що суто функціональні мови уникають оновлень.

— sleske

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

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

Також:

Чи можуть інші методи використовувати змінні класу? Якщо так, то подумайте про зміну класу.
Ваш метод публічний? Якщо відкрито, використовуйте параметри.
Чи може ваш список параметрів бути відповідним чином представлений як хеш / карта / масив / колекція / список / тощо? Якщо так, розгляньте це як варіант.
Ваш метод статичний? Якщо так, використовуйте параметри.

— Тревіс Дж
джерело

Ні, змінні стану самі по собі не викликають побічних ефектів.

Виклик методу встановлення (на структуру даних, що видно в іншому місці) є побічним ефектом.

Ви можете мати структури даних, щоб приховати довгі списки параметрів і ansd, але уникнути побічних ефектів, якщо створити їх відповідно. Ось невеликий приклад (на Java, неперевірений):

class ManyParams {
    final String theName = null;
    final int    theAge = 0:
    ManyParams() {}
    ManyParams(String a, int b) { theName=a; theAge = b; }
    public withName(String n) {
        return new ManyParams(n, this.theAge);
    }
    public withAge(int i) {
         return new ManyParams(theName, i);
    }
}
/// to be used like this
foo(new ManyParams.withName("John").withAge(42));

Звичайно, у конструктора ManyParams все ще буде довгий список параметрів. Але його приховано.

— Інго
джерело