Які існують альтернативи для наскрізних проблем, крім програмно орієнтованого? [зачинено]

Програмування, орієнтоване на аспекти, обіцяє вирішити проблеми з наскрізними проблемами, але я все ще не повністю проданий. Чи були якісь інші спроби вирішити цю проблему?

Коли це можливо, ви можете інкапсулювати наскрізні проблеми в окремі модулі, які потім використовуються у всьому додатку за допомогою введення залежності. Це дозволяє дещо відокремити реалізацію наскрізної проблеми від її використання протягом усього коду.

Однак це не завжди працює елегантно. Саме тому люди намагаються вирішити цю проблему з такими речами, як АОП.

Ще два варіанти, яких я ще не бачив:

Функціональне програмування з монадами та стрілками

У FP ви представляєте наскрізну проблему, як і все інше: як щось, що передаєте під час виклику функції. Оскільки це явно стає втомливим, ви можете використовувати Monads (або, можливо, стрілки), щоб сховати зайву інформацію, яка передається разом.

Найпоширеніший приклад AOP - ведення журналів. За допомогою Monads ви створили б монаду "Logger", яка зберігає список повідомлень. Будь-які функції, що виконуються через LoggerMonad, мають можливість розміщувати повідомлення в журналі. За допомогою стрілок ви б змоделювали весь потік даних програми та працювали в режимі ведення журналу в моделі, де це доречно. Я думаю. Стрілки досить складні.

Програмування на основі об'єктів / компонентів

Щось я досліджував і експериментував для ігрового двигуна. Замість "об'єктів", як в OOP, ви розкладаєте все на пакети даних (компонентів) і сервісів, які працюють над типом компонента. Компоненти групуються за спільними ідентифікаторами, як у реляційній базі даних, а групи пов'язаних компонентів - це Суб'єкти. Щоб додати журнал у такій системі, ви додали б нову службу реєстрації тригерів, на основі яких компонентів проходять через неї.

Обидва способи дозволяють дуже легко працювати наскрізною зміною, але обидва є архітектурними моделями високого рівня. Тож вам, мабуть, потрібно буде використовувати їх з самого початку. Теоретично модель Компонента може бути оброблена в існуючій системі ООП. Я думаю, монади можуть бути занадто, якщо ваша мова досить потужна.

Існує кілька способів вирішити проблеми, пов'язані з перехресним вирізанням:

• Використовуйте кращі шаблони дизайну, ідіоми чи механізми абстрагування : Код може бути перекрестним, навіть якщо його можна модулювати. Щоб зберегти код, вам потрібно буде рефактор використовувати техніку проектування, яка може його модулювати. Таке рефакторинг може запровадити перерізання різного виду, але, сподіваємось, те, що поперечні розрізи є стабільними, і, ймовірно, не зміниться.

• Розвивати багатші мовні особливості : Багато проявів крос-стержування можна вирішити за допомогою кращих механізмів абстрагування, а іноді необхідні нові мовні особливості. Наприклад, більш розвинені мови, які включають функціональні та об'єктно-орієнтовані функції, часто не використовують стільки моделей дизайну, оскільки вони не потрібні. Зауважте, що самі дизайнерські шаблони можуть мати перекрестний характер , оскільки вони описують ролі декількох різних об'єктів та класів. На Java рефлексію часто можна використовувати замість аспекту, хоча і за більш високу вартість виконання. Наприклад, використовуючи рефлексію, ви можете підтримати шаблон відвідувачів протягом сотень класів за допомогою лише декількох рядків коду. DJ-бібліотеказ Північного Сходу - це одне рефлексивне рішення, яке робить саме це. Міксини є потужною технікою, доступною в C ++ (але не на Java) і може надати вам кілька таких же випадків використання як аспект.

• Забезпечити кращу підтримку інструментів : Такі методи, як використання grepта виконання операцій рефакторингу, можуть вирішувати проблеми, пов’язані з кодом перехресного перерізу. Наприклад, ім'я методу, оголошеного в інтерфейсі, може вирізати всю програму. (Зверніть увагу на технічну різницю тут: перехрестя саме ім'я методу, а не реалізація методу.) Зазвичай це не проблема в IDE, як Eclipse, де ви можете використовувати "перейменувати рефакторинг", щоб змінити всі місця у вашому коді, які використовують ім’я. Таким чином, можливо, не потрібно мовних функцій, коли середовище програмування для вас достатньо виразне.

• Використання мов, орієнтованих на домен: Ранні мови аспектів, які виходили перед AspectJ, були доменними і застосовувались лише до певних проблем, таких як синхронізація потоків або аналіз потоку даних для ефективного поєднання функціональних композицій. Ці мови були експериментальними, але здавались надзвичайно успішними в модуляризації проблем, які в іншому випадку були перехресними.

• Використовуйте методи генеративного програмування : Підняття мета-рівня може вважатися технікою впровадження програмно-орієнтованого програмування, але це досить велика область, що вона виходить за рамки простих аспектів. Генеративні прийоми (де програма генерує вихідний код для іншої програми) також пов'язані з доменними мовами.

Зважаючи на все це, я вважаю, що вивчення АОП є доцільним. AOP може допомогти вам розширити свої уявлення про код, навіть якщо ви не використовуєте мову AOP.

Взагалі елементи тегування коду з декларативною особливістю, але конкретно системою атрибутів у світі C # /. NET / Mono.

Я не фахівець з АОП, але, читаючи про нього протягом багатьох років, це завжди здавалося слабшою формою метапрограмування, запропонованого Ліспом , особливо частинами, такими як його протокол метаоб'єктів.

Це, мабуть, не дивно: Грегор Кіцалес був одним з авторів AMOP, а згодом написав AspectJ для Java!