Znalazłem ten cytat w „ Radości Clojure'a ” na str. 32, ale ktoś powiedział mi to samo podczas kolacji w zeszłym tygodniu i słyszałem to także w innych miejscach:
[A] wadą programowania obiektowego jest ścisłe powiązanie funkcji i danych.
Rozumiem, dlaczego niepotrzebne sprzężenie jest złe w aplikacji. Nie mam też wątpliwości, że należy unikać stanu zmiennego i dziedziczenia, nawet w programowaniu obiektowym. Ale nie rozumiem, dlaczego przyczepianie funkcji do klas jest z natury złe.
Mam na myśli, że dodanie funkcji do klasy wydaje się oznaczać tagowanie poczty w Gmailu lub umieszczanie pliku w folderze. Jest to technika organizacyjna, która pomaga znaleźć ją ponownie. Wybierasz niektóre kryteria, a następnie łączysz je razem. Przed OOP nasze programy były dość dużymi torbami metod w plikach. To znaczy, musisz gdzieś umieścić funkcje. Dlaczego ich nie uporządkować?
Jeśli jest to zawoalowany atak na typy, dlaczego nie powiedzą po prostu, że ograniczenie typu wejścia i wyjścia do funkcji jest niewłaściwe? Nie jestem pewien, czy mógłbym się z tym zgodzić, ale przynajmniej znam argumenty za i przeciw bezpieczeństwu. To brzmi dla mnie jak osobna sprawa.
Pewnie, czasami ludzie źle to rozumieją i przypisują funkcjonalność niewłaściwej klasie. Ale w porównaniu z innymi błędami wydaje się to bardzo niewielką niedogodnością.
Więc Clojure ma przestrzenie nazw. W jaki sposób naklejanie funkcji na klasę w OOP różni się od naklejania funkcji w przestrzeni nazw w Clojure i dlaczego jest tak źle? Pamiętaj, funkcje w klasie niekoniecznie działają tylko na członków tej klasy. Spójrz na java.lang.StringBuilder - działa na dowolnym typie odwołania lub poprzez automatyczne boxowanie na dowolnym typie.
PS Ten cytat odnosi się do książki, której nie przeczytałem: Multiparadigm Programming in Leda: Timothy Budd, 1995 .