Śmierć technologii OOP [zamknięte]

Wiele razy słyszałem o programowaniu aspektowym, głównie że jest to technologia „następnej generacji” w programowaniu i zamierza „zabić” OOP.

Czy to jest poprawne? Czy OOP umrze lub co może być tego przyczyną?

Za każdym razem, gdy ktoś powie Ci, że jedna technologia oprogramowania zabije inną lub zdominuje cały rynek / zastosowanie / odbiorców, pamiętaj o tym:

Zdrowy (dynamiczny, ale stabilny) ekosystem składa się z wielu różnych gatunków.

Oznacza to, że każda nowa technologia hiper przechodzi przez krzywą szumu, a na końcu znajdzie swój specyficzny (-e) cel w czasie i doświadczeniu z nią.

Oznacza to również, że tak ekstremalna koncepcja, jak programowanie zorientowane na aspekt, jest przydatna, jeśli jest potrzebna, co oznacza, że ​​nie zawsze i niezbyt często z powodu domniemanych kosztów.

Ale ma już swoje miejsce, takie jak programowanie OOP, programowanie ogólne, programowanie funkcjonalne, programowanie proceduralne itp.

Czy zauważyłeś, że języki, które są częściej używane (i kontrowersyjnie popularne) i szeroko rozpowszechnione w prawdziwym życiu, nie są „czyste”? Dzieje się tak, ponieważ zezwolenie na kilka paradygmatów sprawia, że ​​są one bardziej elastyczne w zmienianiu kontekstu w czasie i wypełniają więcej nisz użytkowych.

OOP nie umrze z powodu AOP. AOP dodaje pewną wartość, ale żyje w doskonałym współistnieniu z OOP. Nie sądzę, że programowanie funkcjonalne zabije także OOP. OOP jest zbyt dobry dla wielu rodzajów domen problemowych, nie ma sensu zastępować go paradygmatem funkcjonalnym.

Paradygmaty przychodzą i odchodzą, ale starszy kod jest wieczny. Zawsze będzie kod C ++ do utrzymania, więc OOP nigdy nie umrze całkowicie.

Krótka odpowiedź: Nie, nie sądzę.

Dłuższa odpowiedź: z tego, co rozumiem na temat AOP, nie jest on sam w sobie paradygmatem programowania (jako że nie zastępuje OOP), ale raczej dodatkiem, zestawem narzędzi, który pomaga pisać krótsze metody, prostsze klasy z pojedynczą odpowiedzialnością itp. Ale to nie zastępuje OOP.

Tym, co (przynajmniej częściowo) zastępuje lub dodaje do OOP, jest programowanie funkcjonalne, które w rzeczywistości jest innym paradygmatem programowania (chociaż można go łączyć z OOP, na przykład w języku programowania Scala ). Preferuje niezmienne struktury danych i wszelkiego rodzaju fantazyjne funkcje, które zwykle frustrują programistów OOP, szczególnie jeśli chodzi o współbieżność.

O OO mówi się dziś mniej, ponieważ zakłada się, że jest to de facto podejście w wielu sytuacjach. AOP nigdy nie zerwał się z ziemią jako ruch masowy.

Pamiętam, jak po raz pierwszy usłyszałem o programowaniu zorientowanym na aspekt w programie OOPSLA '97. Powiedzieli, że wtedy zabije OO. Od tego czasu OO przekroczyło najśmielsze oczekiwania. AOP jest wciąż mało znany, zasadniczo nie ma wpływu na przemysł komputerowy. Myślę, że odpowiedź jest oczywista, że ​​AOP nie jest zabójcą OO.

Spójrz na niektóre istniejące systemy AOP. Zależą od tego, że masz kod napisany w jakiejś formie - na przykład Spring AOP polega na tym, że masz zdefiniowane metody w klasie. Castle Windsor obsługuje go w języku C #, który jest językiem obiektowym.

Możesz teoretycznie przejść z OOP na programowanie strukturalne i nadal zachować AOP, ale w praktyce byłoby to trudne. Łatwo jest podklasować coś, zastąpić odpowiednią metodę, aby wywołać odpowiednie filtry przed / po i przekazać to w procesie wstrzykiwania zależności.

To jest cholernie trudne w porównaniu do przepisywania statycznych wywołań metod, aby kierować do metody trampoliny zaprojektowanej do wywoływania filtrów zdefiniowanych przez użytkownika.

Tak więc ze wspólnego punktu widzenia implementacji AOP wymaga OOP.

Chociaż OOP z pewnością nie jest srebrną kulą, to samo można powiedzieć o AOP. Obsługuje projektowanie oparte na komponentach, jednak w schemacie większym komponenty są nowymi obiektami, a interfejsy komponentów są w zasadzie transakcyjną listą metod, co NIE jest prawdziwym OOP.

Dalsze AOP i projektowanie oparte na komponentach wspierają Anemiczny model danych, który jest bardziej krytykowany przez inteligentniejszych ludzi niż ja.

http://martinfowler.com/bliki/AnemicDomainModel.html

(Wiem, że powyższy artykuł jest stary, ale zaskakująco istotny)

Najważniejsze jest to, że systemy AOP są tutaj, ale są dalekie od ideału. Żaden system nie jest idealny.