Dziś jedynie dwa linki, które uważam za godne polecenia.
Przeczytałem niedawno tekst, który lekko zachwiał moim światopoglądem: Aristotle's Error or Agile Smagile. Tekst traktuje ogólnie o historii - znajdziecie tam również rzekomą genezę Object Oriented.
Rzekomo pierwotnie wcale nie chodziło o modelowanie świata, lecz o zabawy ze stertą - co będzie gdy zamiast chwilowo przechowywać zmienne na stosie wrzucimy je na dłużej do sterty.
Teorię OO Analysis i OO Design rzekomo "dorobiono" później. Tak, tak, wiem - sam jestem w szoku podobnym do tego gdy wydedukowałem, że nie ma żadnego św Mikołaja;P
Nie wiem na ile historia o pierwocinach OO jest prawdziwa, ale tym razem wielki szacunek dla Uncle Boba za zdystansowane podejście.
Kolejny link to ciekawa prezentacja człowieka, któremu doświadczenie również pozwala zdystansować się od mainstreamu Are We There Yet?. Prezentacja pozwala uświadomić sobie ograniczenia OO oraz wyjaśnia (tym, którzy jeszcze tego nie widzą) dlaczego niektóre wydawałoby się proste języki wprowadzają wysoką złożoność (przypadkową).
Zobaczycie też jak bardzo podobne są do siebie języki, o które często spieramy się "który lepszy". Nie brakuje też aluzji do takich "przełomowych usprawnień" jak usunięcie średników:) Dowiecie się również z czego wg autora prezentacji wynika potrzeba posiadania testów:)
//=======================
Od razu ostrzegam, że treści kryjące się pod linkami są mocno filozoficzne, ale może warto oderwać się na chwilę od kodu aby później móc spojrzeć na niego inaczej...
1 komentarz:
No jakoś nie wierzę, że OOP zaczęło się od zabawy w alokację pamięci i stertę. :-)
Większość źródeł za "przyczynę" powstania OOP podaje język Simula przeznaczony nie do ogólnego programowania tylko do symulacji. Pomysł klas/obiektów poprawia rozumienie kodu (łatwiej mówić o obiektach niż o procedurach i strukturach), do tego OOP powinno poprawiać cohesion i coupling w kodzie. Poza tym jest to "zwykłe" programowanie imperatywne.
W prezentacji była mowa o programowaniu na obiektach immutable i funkcjonalnym. Często ułatwia to kodowanie (nie ma side effects i można algorytmy łatwo zrównoleglać), ale koszt zużycia pamięci jest duży, bo każda operacja "przypisania" wartości pola w obiekcie oznacza płytkie skopiowanie tego obiektu a następnie wszystkich obiektów które do danego obiektu się odnoszą. Jeśli struktura obiektów jest mocno zagnieżdżona, jest to megaproblem. Ja bym raczej w programowaniu na obiektach immutable czy funkcjonalnym nie widział złotego panaceum (co można wywnioskować z tej prezentacji) tylko rozwiązania niektórych praktycznych problemów:
- niektóre problemy matematyczne
- systemy kontroli wersji, np. SVN używa dokładnie tego sposobu z drzewem pokazanego na prezentacji w momencie komitowania
- proste obiekty będące "liśćmi" albo "prawie liśćmi" drzewa obiektów (liczby, napisy, daty, liczby zespolone, adresy, ...)
- wzorzec prezentacji PresentationModel - nie jest to może immutable, ale w obiekcie przeważają "pure functions" z tej prezentacji i getery, a jest mało seterów; pozwala w prosty sposób tworzyć nawet bardzo złożone GUI
Moim zdaniem najlepsze co mamy to programowanie imperatywne + OOP (+ dodatki jak AOP, metaprogramowanie, typy generyczne, systemy typu Drools czy elementy programowania funkcjonalnego). W najbliższym czasie nie spodziewałbym się tu rewolucji. :-)
Prześlij komentarz