Jakie są wady programowania zorientowanego na aspekt (AOP)?

Question

Jakie są możliwe i krytyczne wady programowania zorientowanego na aspekt?

Na przykład: cryptic debugowania dla początkujących (wpływ czytelności)

Answer 1

• Słabe wsparcie toolchain - debuggery, profilowania etc nie może wiedzieć o AOP i tak może pracować na kodzie jak gdyby wszystkie aspekty zostały zastąpione przez kod proceduralny
• Kod uwędzić - małe źródło może prowadzić do znacznie większej kodu wynikowego jako kod „utkany” całej bazy kodu

Answer 2

nie nazwałbym go krytyczną wadą, ale największym problemem widziałem to jeden z doświadczeń programistów i Zdolność adaptacji. Nie wszyscy deweloperzy rozumieją różnicę między programami deklaratywnymi i imperatywnymi.

Używamy policy injection application block w EntLib 4.1 dość szeroko, jak również Unity dla DI i to po prostu nie jest czymś, co szybko zapada w pamięć dla niektórych osób. Ciągle sam się tłumaczę tym samym ludziom, dlaczego aplikacja nie zachowuje się w sposób, jakiego oczekują. Zaczyna się od tego, że wyjaśniają coś, a ja mówię "zobacz tę deklarację powyżej metody". :) Niektórzy ludzie dostają to od razu, kochają to i stają się niezwykle produktywni - inni walczą.

Krzywa uczenia się nie jest unikatowa dla AOP, ale wydaje się, że ma wyższą krzywą uczenia się od innych rzeczy, które napotyka przeciętny programista.

Answer 3

Konserwacja i debugowanie. Z aop, nagle masz kod, który jest uruchamiany w danym punkcie (wejście metody, wyjście, cokolwiek), ale po prostu patrząc na kod, nie masz pojęcia, że ​​jest on nawet wywoływany, zwłaszcza jeśli konfiguracja aop jest w innym pliku podobnie jak konfiguracja xml. Jeśli rada powoduje pewne zmiany, to podczas debugowania aplikacji rzeczy mogą wyglądać dziwnie bez żadnego wyjaśnienia. Nie dotyczy to tylko początkujących.

Answer 4

Uważam, że największą wadą jest używanie AOP. Ludzie używają go w miejscach, w których na przykład nie ma sensu i nie używa go tam, gdzie jest.

Na przykład, wzór fabryczny jest oczywiście czymś, co AOP może zrobić lepiej, ponieważ DI może również zrobić to dobrze, ale wzorzec obserwatora jest prostszy, gdy używa się AOP, podobnie jak wzór strategii.

Testowanie jednostkowe będzie trudniejsze, szczególnie jeśli wykonujesz tkactwo w czasie wykonywania.

Jeśli tka się w środowisku wykonawczym, oznacza to również, że osiągnął wydajność.

Dobrym sposobem modelowania tego, co dzieje się podczas mieszania AOP z klasami, jest problem, ponieważ UML nie wydaje mi się dobrym modelem w tym momencie.

O ile nie używasz Eclipse, to narzędzia mają problemy, ale dzięki Eclipse i AJDT AOP jest znacznie łatwiejsze.

Na przykład nadal używamy junit i nunit, więc musimy zmodyfikować nasz kod, aby umożliwić uruchamianie testów jednostkowych, podczas korzystania z uprzywilejowanego trybu AOP może wykonywać lepsze testy jednostkowe, testując również metody prywatne, a my nie musimy zmienić nasze programy tylko po to, aby mogły pracować z testowaniem jednostkowym. Jest to kolejny przykład niezrozumienia, w jaki sposób AOP może być pomocny, nadal jesteśmy przykutymi na wiele sposobów w przeszłość dzięki ramom testów jednostkowych i aktualnym implementacjom wzorców projektowych i nie widzimy, w jaki sposób AOP mógłby nam pomóc w lepszym kodowaniu.

Answer 5

Jeśli chodzi o argument dotyczący konserwacji/debugowania, programowanie aspektowe idzie w parze ze wszystkimi innymi aspektami zwinnych praktyk programistycznych.

Te praktyki mają tendencję do usuwania debugowania z obrazu, zastępując go testowaniem jednostkowym i testowym rozwojem.

Ponadto może być o wiele łatwiejsze zachowanie niewielkiego, czystego odcisku kodu z poradą niż duży, niezrozumiały ślad kodu bez porady (rada jest tym, co przekształca duży, niezrozumiały ślad kodu w mały, wyraźny ślad kodu).

Answer 6

Ponieważ moc AOP, jeśli istnieje błąd w przekroju, może powodować powszechne problemy. Z drugiej strony, ktoś może zmienić punkty złączenia w programie - np. Zmieniając nazwy lub przenosząc metody - w sposób, jakiego twórca aspektu nie oczekiwał, z niezamierzonymi konsekwencjami. Zaletą modularyzacji zagadnień przekrojowych jest umożliwienie programistom łatwego wpływania na cały system.

Answer 7

Myślę, że największym problemem jest to, że nikt nie wie sposobu definiowania semantyki aspekcie lub jak deklarować dołączyć punktów niż proceduralnie.

Jeśli nie możesz zdefiniować, co dany aspekt wykonuje niezależnie od kontekstu, w którym zostanie osadzony, lub zdefiniować efekty, które ma, w taki sposób, aby nie uszkodzić kontekstu, w którym jest osadzony, Ty (i narzędzia) nie możesz uzasadnić, co robi niezawodnie. (Zauważysz, że najczęstszym przykładem aspektów jest "logowanie", które jest zdefiniowane jako "napisz trochę rzeczy do strumienia dziennika, o którym aplikacja nic nie mówi", ponieważ jest to całkiem bezpieczne). To narusza kluczowe pojęcie Davida Parnasa: information hiding. Jednym z najgorszych przykładów aspektów, które widzę są te, które wstawiają prymitywy synchronizacji do kodu; wpływa to na kolejność możliwych interakcji, jakie może mieć kod. Skąd możesz wiedzieć, że to jest bezpieczne (czy nie będzie impasu? Nie będzie livelocku, czy nie zabezpieczysz się, czy będzie można je odzyskać w obliczu odrzuconego wyjątku u partnera synchronizacji?), Chyba że aplikacja robi już tylko trywialne rzeczy.

Punkty łączenia są obecnie zwykle definiowane poprzez podanie symbolu wieloznacznego (np. "Umieść ten aspekt w dowolnej metodzie o nazwie" DataBaseAccess * "). Aby to zadziałało, osoby piszące te metody muszą zasygnalizować zamiar ich kod, który należy zobrazować, nazywając ich kod w zabawny sposób, który nie jest modułowy, a co gorsza, dlaczego ofiara aspektu musi wiedzieć, że istnieje? Zastanów się, co się stanie, jeśli po prostu zmienisz nazwę niektórych metod; Dłuższe wstrzyknięcie tam, gdzie jest to potrzebne, a aplikacja się zepsuje Potrzebne są specyfikacje punktów sprzężenia, które są zamierzone, w jakiś sposób aspekt musi wiedzieć, gdzie jest to potrzebne, bez konieczności umieszczania przez programistów znaku neonowego w każdym punkcie użycia. ma pewne punkty sprzężenia związane z przepływem sterowania, które wydają się nieco lepsze w tym reg ard).

Aspekty są ciekawym pomysłem, ale sądzę, że są one niedojrzałe technologicznie. A ta niedojrzałość sprawia, że ​​ich użycie jest kruche. I tu właśnie leży problem. (Jestem wielkim fanem zautomatyzowanych narzędzi inżynierii oprogramowania [patrz mój bio] po prostu nie w ten sposób).