Аспектно-ориентирано програмиране: Разлика между версии

Изтрито е съдържание Добавено е съдържание
Denitsar (беседа | приноси)
Denitsar (беседа | приноси)
Ред 181:
// return temp * temp
}
Всъщност, един пойнткът ({{lang-en|[[:en:Pointcut|pointcut]]}}) може да зависи от времето за изпълнение и това да го прави нестатично детерминиран. Това обстоятелство може да бъде смекчено, но не и преодоляно чрез статичен анализ и IDE (Интегрирана среда за разработка) поддръжка, показваща кои адвайсессъветници({{lang-en|advices - съвети - отнася се за допълнително добавено поведение към съществуващ код}}) биха съвпаднали.
Сред общите критики е и мнението, че претенциите на АОП да подобрява „както модулността ({{lang-en|modularity}}), така и структурата на кода“ са неоснователни. Според критиците, вместо това АОП подкопава тези цели и пречи на „независимата разработка и разбираемост на програмите“. По-конкретно, количественото определяне чрез пойнткъти е в разрез с модулността: по принцип, човек трябва да познава цялата програма, за да разсъждава върху динамичното изпълнение на аспектно-ориентирана програма. Освен това, докато целите на АОП (модулиране на кроскътинг дялове) са разбираеми, неговата дефиниция е неясна и трудно се отличава от други, вече установени техники. Всъщност, аспектите могат да се прилагат към себе си, което ще доведе до проблеми като [[:en:Liar paradox|парадокса на лъжеца]].
Технически насочените критики пък посочват количественото определяне на пойнкъти (дефиниране на мястото на изпълнение на адвайсите) като „изключително чувствително към промени в програмата“ – проблем известен още като “fragile pointcut problem” ({{lang-en|„проблем на чупливите пойнкъти“}}). Проблемите с пойнткъти се считат за неразрешими - ако заменим количественото им определяне с експлицитни анотации, ще получим атрибутно-ориентирано програмиране ({{lang-en|[[:en:Attribute-oriented programming|Attribute-oriented programming]]}}), което пък среща същите проблеми, за чието решение е създадено АОП.