Na stronie 839 drugiego wydania Steve McConnell omawia wszystkie sposoby, w jakie programiści mogą „pokonać złożoność” w dużych programach. Jego wskazówki kończą się tym stwierdzeniem:
„Programowanie obiektowe zapewnia poziom abstrakcji, który dotyczy jednocześnie algorytmów i danych , rodzaj abstrakcji, której nie zapewnił sam rozkład funkcjonalny”.
W połączeniu z konkluzją, że „zmniejszenie złożoności jest prawdopodobnie najważniejszym kluczem do bycia efektywnym programistą” (ta sama strona), wydaje się, że jest to wyzwanie dla programowania funkcjonalnego.
Debata między FP i OO jest często omawiana przez zwolenników FP wokół kwestii złożoności, które wynikają konkretnie z wyzwań związanych z współbieżnością lub równoległością. Ale współbieżność z pewnością nie jest jedynym rodzajem złożoności, który programiści muszą pokonać. Być może skupienie się na zmniejszeniu jednego rodzaju złożoności znacznie go zwiększa w innych wymiarach, tak że w wielu przypadkach zysk nie jest wart kosztu.
Jeśli zmienilibyśmy warunki porównania FP i OO z konkretnych kwestii, takich jak współbieżność lub możliwość ponownego użycia, do zarządzania globalną złożonością, jak wyglądałaby ta debata?
EDYTOWAĆ
Kontrast, który chciałem podkreślić, polega na tym, że OO wydaje się hermetyzować i abstrahować od złożoności zarówno danych, jak i algorytmów, podczas gdy programowanie funkcjonalne wydaje się zachęcać do pozostawiania szczegółów implementacji struktur danych bardziej „ujawnionych” w całym programie.
Patrz np Stuart Halloway (zwolennikiem Clojure FP) tutaj mówiąc, że „nadmierne specyfikacja typów danych” jest „negatywna konsekwencja idiomatycznym stylu oo” i faworyzowanie konceptualizacji adresową jako prosty wektora lub map zamiast bogatszej obiektu OO z dodatkowymi (nie wektorowymi i niemapowymi) właściwościami i metodami. (Również zwolennicy projektowania i zarządzania opartego na domenie mogą powiedzieć, że wystawienie książki adresowej jako wektora lub mapy prześwietla enkapsulowane dane metodami, które są nieistotne, a nawet niebezpieczne z punktu widzenia domeny).