Які переваги та недоліки використання парадигми орієнтованого на аспект програмування [закрито]

Ось так ось питання: Які переваги та недоліки використання парадигми орієнтованого на аспект програмування.

Мої переваги та недоліки поки що:

Переваги:

• Доповнює орієнтацію об'єкта.
• Модуляція наскрізних питань стосується вдосконалення ремонтоздатності та зрозумілості коду.

Недолік:

• Не найпростіші концепції, які можна зрозуміти - не так добре зафіксовані як ОО
• OO йде досить далеко в розділенні проблем ...

Хтось хотів би оскаржити будь-яке з них / додати своє власне?

Велике спасибі, Дж

З точки зору програміста, девізом якого є "Keep It Simple Stupid", оцінювати використання таких моделей небезпечно. Щодо того, що вона намагається здійснити, це робить програму набагато складнішою для розуміння і, отже, легше її зламати.

Геній хорошого програмування полягає у своїй простоті іронічно. Складні програми можуть працювати, але це кошмар, коли йдеться про технічне обслуговування, і якщо ви вважаєте, що 2/3 третини часу, який витрачає програміст, приділяється виправленню помилок у програмах, це зрештою не окупається.

Розподіл функціональних можливостей поза місцем роботи збільшує складність та проблеми, що знаходяться на відстані.

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

Додаткові переваги (не всі)

• Повторне використання класів та аспектів, завдяки модульності
• Зниження витрат на кодування завдяки модульності та повторному використанню
• Коротший код завдяки можливості мати аспект з кодом, який інакше був би реалізований (розпорошений) на кілька класів
• Можливість додавати поведінку до класу без введення в нього коду, не пов'язаного з його основною відповідальністю
• Можливість перевизначити семантику методів / класів, не повідомляючи про це клієнтських класів

Недоліки

• Час виконання під час використання деяких конструкцій, наприклад, cflow

Недолік: Погана підтримка ланцюга інструментів: - налагоджувач та профілер можуть не знати про "програмування, орієнтовану на аспекти", тому вони можуть працювати над кодом так, ніби всі аспекти були замінені процедурним кодом.