Długa lista parametrów a długa lista zmiennych stanu

W książce C ++ autor mówi, że nie potrzebujemy już funkcji z długą listą parametrów, ponieważ większość parametrów można przekształcić w zmienne stanu w klasie. Z drugiej strony, funkcjonalny podręcznik programowania mówi, że zmienne stanu są złe, ponieważ powodują skutki uboczne, które powodują podatność na błędy i trudność do zrównoleglenia kodu. Jestem zakłopotany. Czy kod powinien unikać polegania na zmiennych stanu w jak największym stopniu, przenosząc jego zmienną stanu na listę parametrów funkcji?

functional-programming object-oriented-design

— TomCaps
źródło

Czy oryginalna książka komentowała C ++ jako język funkcjonalny?

— Martin York,

Odpowiedzi:

Zależy, jeśli programujesz w paradygmacie procedurallub functional. Stan zmienny jest wymagany dla pierwszego, a okaleczający dla drugiego. To są jabłka i pomarańcze. Obaj mają rację w sprawie bailiwick!

Możesz zastosować pojedyncze przypisanie i inne techniki funkcjonalne do imperatywnych języków proceduralnych, stan niezmienny sprawia, że współbieżne programowanie jest bardziej deterministyczne, ale uczynienie każdego obiektu niezmiennym w języku takim jak Java lub C ++ jest prawie niemożliwe, ponieważ ich modele pamięci nie obsługują łatwo tego paradygmatu.

:Dzięki! Książka << 97 rzeczy, które powinien wiedzieć każdy programista >> mówi, że powinniśmy stosować funkcjonalne zasady programowania, takie jak unikanie skutków ubocznych. Czy nie możemy zastosować zasad programowania funkcjonalnego w imperatywnym kontekście kodu?

— TomCaps,

Stan nie jest wymagany do programowania proceduralnego. Jest to powszechne, ale nie wymagane. To, że jest powszechne, wynika bardziej z nawyków niż czegokolwiek innego. Chociaż przyznam, że z pewnością istnieją sytuacje, w których utrzymanie zmiennej (stanu) jest łatwiejsze niż alternatywy (np. Przetwarzanie asynchroniczne).

— Marjan Venema,

@Marjan wszystko, co ma niezmienne zmienne, to stan

@Jarrod: Teraz mnie zdezorientowałeś. Ponownie czytam twoją odpowiedź. Widzę, że przegapiłem „Zmienny” w „Wymagany jest stan Zmienny”. Ale twój komentarz wydaje się mówić, że posiadanie niezmiennych zmiennych jest stanem. Nie rozumiem Może dlatego, że nie jestem przyzwyczajony do rzucania się i myślenia o zmienności i niezmienności w tych kategoriach. Wszelkie referencje do przeczytania?

— Marjan Venema,

@MarjanVenema: Tak, posiadanie niezmiennych zmiennych jest stanem. Różnica w obsłudze stanu między programowaniem proceduralnym a funkcjonalnym nie polega na tym, że proc.prog. ma stan, a funkcjonalny nie - raczej różnica polega na tym, że proc. żarcie. ma stan zmienny , podczas gdy stan jest zawsze niezmienny w (czystym) programowaniu funkcjonalnym. Zobacz np. En.wikipedia.org/wiki/Purely_functional , który wyjaśnia, że czysto funkcjonalne języki unikają aktualizacji.

— sleske,

Jeśli dobrze rozumiem twoje pytanie, zastanawiasz się, jakie warunki kwalifikują albo użycie parametru lub zmiennej klasy / member / field / etc? Zakładam, że masz na myśli metodę, a nie funkcję. Jeśli chodzi konkretnie o C ++, sugeruję przeniesienie pytania do przepełnienia stosu.

Długa lista parametrów może być znakiem, że może być konieczne przeformułowanie metody na zestaw bardziej szczegółowych. Zasadniczo użycie parametrów sprawi, że kod będzie luźniej sprzężony. Nie jestem pewien, czy jest to prawdą w przypadku większości współczesnych języków OO, ale tworzenie obiektów może być kosztowne, zwłaszcza jeśli w grę wchodzi wiele zmiennych klas; tak więc, jeśli zmienne klasy były obiektami i były często przywoływane w programie, można je uzasadnić jako zmienne klasy.

Również:

Czy inne metody mogą korzystać ze zmiennych klas? Jeśli tak, rozważ użycie zmiennych klasowych.
Czy twoja metoda jest publiczna? Jeśli publiczny, użyj parametrów.
Czy twoja lista parametrów może być odpowiednio reprezentowana jako skrót / mapa / tablica / kolekcja / lista / etc? Jeśli tak, rozważ tę opcję.
Czy twoja metoda jest statyczna? Jeśli tak, użyj parametrów.

— Travis J
źródło

Nie, zmienne stanu same w sobie nie powodują skutków ubocznych.

Wywołanie metody settera (w strukturze danych widocznej gdzie indziej) to efekt uboczny.

Możesz mieć struktury danych, aby ukryć długie listy parametrów i uniknąć skutków ubocznych, jeśli odpowiednio je skonstruujesz. Oto mały przykład (w Javie, niesprawdzony):

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));

Oczywiście konstruktor ManyParams nadal będzie miał długą listę parametrów w ten sposób. Ale jest ukryty.

— Ingo
źródło