Я багато разів чув про аспектно-орієнтоване програмування, головним чином, що це технологія "наступного покоління" в програмуванні і збирається "вбити" OOP.
Це право? Чи помер ООП чи це може бути причиною цього?
Технологія OOP смерть [закрито]
Відповіді:
Кожен раз, коли хтось скаже вам, що одна програмна технологія вб’є іншу чи домінує над усім ринком / використанням / аудиторією, пам’ятайте про це:
Здорова (динамічна, але стабільна) екосистема складається з безлічі різних видів.
Це означає, що будь-яка нова завищена технологія пройде через криву ажіотажу і, врешті-решт, знайде свою конкретну (цільову) ціль через час та досвід з нею.
Це також означає, що таке екстремальне поняття, як аспект-орієнтоване програмування, є корисним, якщо воно необхідне, тобто не завжди та не дуже часто через неяві витрати.
Але у нього вже є своє місце, як OOProgramming, як загальне програмування, як функціональне програмування, як процедурне програмування тощо.
Ви помічали, що мови, які є більш вживаними (і суперечливо популярними) і широко поширеними в реальному житті, "не чисті"? Це тому, що, якщо дозволити декілька парадигм, робить їх більш гнучкими до зміни контексту через час, і вони заповнюють більше ніш використання.
1
+1 для "не чисто". Чисті мови OOP помітно мертві, за винятком дуже нішевих програм / наукових кадрів.
—
jv42
Що б ми вважали чистою мовою ОО? Невеличка розмова?
—
Чжехао Мао
OOP не помре через AOP. AOP додає певної цінності, але він живе в ідеальному співіснуванні з OOP. Я не думаю, що функціональне програмування теж не вб'є OOP. OOP занадто добре підходить для багатьох видів проблемних доменів, не було б сенсу замінювати його функціональною парадигмою.
Це дуже суб'єктивно. Я не думаю, що OOP добре підходить для конкретної проблемної області, це добре підходить до того, як конкретний розробник приймає рішення. OOP не загине, оскільки розробники не можуть робити перемикання парадигми.
—
Райнос
Класичним прикладом, коли OOP добре підходить, є графічні інтерфейси. Важко уявити API для набору інструментів GUI, який не є OO, навіть якщо мова не є. (Зрозуміло, зазвичай не використовується термін проблемний домен). Наведіть приклад реальної проблемної області, в якій OOP добре підходить: Автоматизація складів. Моделювання транспортних засобів для зберігання та пошуку та їх діяльність - це те, що ООП відчуває себе природним чином.
—
користувач281377
@ammoQ, GUI є жахливими, коли вони виражаються в OO. Ось чому всі API пересуваються до DSL (WPF тощо). Не важко уявити, скажімо, Tk - жодного сліду OOP немає, але все-таки він чудовий (для програмування, а не для його зовнішнього вигляду та відчуття), набагато краще, ніж будь-який із перекритих наборів інструментів Java OO. OOP дуже добре вписується в будь-які симулятори на основі агентів (як у тих, що ви перераховували), але це невелика частка існуючих проблем.
—
SK-логіка
Переглядаючи перші приклади tk, які я міг знайти, як це не ОО? З підручника: "Віджети - це об'єкти, екземпляри класів, які представляють кнопки, кадри тощо". tkdocs.com/tutorial/concepts.html Навіть більше, самі DSL дуже залежать від програми OO. Тож я не дуже розумію, що ви намагаєтеся сказати?
—
Інка
@ Sk-логіка, @ammoQ, @Raynos, @jkocking, я просунув це питання самостійно: programmers.stackexchange.com/questions/88385/… Мені б дуже цікаво отримати більше пояснень з цього приводу, я дуже зацікавлений вчитися.
—
Інка
Коротка відповідь: Ні, я не думаю.
Більш довга відповідь: Із того, що я розумію в AOP, це не парадигма програмування сама по собі (як, наприклад, вона не замінює OOP), а більше доповнення, набір інструментів, який допомагає писати більш короткі методи, простіші класи з однією відповідальністю , тощо. Але це не замінює OOP.
Те, що робить (принаймні частково) заміною або доповненням OOP, - це функціональне програмування, яке насправді є іншою парадигмою програмування (хоча її можна змішувати з OOP, наприклад, мовою програмування Scala ). Він надає перевагу незмінним структурам даних та всіляких вигадливих функцій, які, як правило, засмучують розробників OOP, особливо якщо мова йде про одночасність.
Функціональний <-> Імператив - це лінія. OOP паралельно йому. Я думаю, що процедура є на іншому кінці ООП, але я не впевнений. Звичайно, цікаво, що функціональна парадигма старша за парадигму OOP :)
—
Raynos,
@Raynos, прямої лінії немає. OOP - це лише одна крихітна металінгвістична абстракція всередині величезного (нескінченного) набору можливих абстрактних мов. І звичайно, вкрай нерозумно обмежувати себе будь-яким із них.
—
SK-логіка
Про OOP сьогодні говорять рідше, оскільки в багатьох ситуаціях фактично це підхід. АОП ніколи не піднімався з землі, як будь-який вид масового руху.
Я пам’ятаю, як слухав про програмування, орієнтовану на аспекти, вперше, сидячи в навчальному посібнику OOPSLA '97. Тоді вони сказали, що це збирається вбити ОО тоді. З тих пір ОО тільки вийшло за рамки найсміливіших очікувань. AOP, досі ледве відомий, фактично не впливаючи на обчислювальну галузь. Я думаю, що відповідь очевидна, що AOP не є вбивцею OO.
Подивіться на деякі існуючі системи АОП. Вони залежать від того, чи будете мати якийсь код, записаний у якійсь формі - наприклад, Spring AOP покладається на те, щоб ваші методи були визначені в класі. Castle Windsor підтримує його в C #, що є об'єктно-орієнтованою мовою.
Теоретично ви могли перейти від OOP до структурованого програмування і все ще зберігати AOP, але на практиці це буде складно. Легко щось підкласифікувати, замінити відповідний метод, щоб викликати відповідні до / після фільтрів, і передавати це в процесі введення залежності.
Це важко порівняно з перезаписом статичних викликів методів для переходу на батутний метод, призначений для виклику визначених користувачем фільтрів.
Отже, з загальної точки зору впровадження, AOP вимагає OOP.
Хоча OOP, звичайно, не є срібною кулею, те саме можна сказати і для AOP. Він підтримує дизайн на основі компонентів, однак у грандерній схемі ваші компоненти - це нові об'єкти, а інтерфейси компонентів - це в основному транзакційний перелік методів, що НЕ відповідає дійсності OOP.
Подальший АОП та дизайн на основі компонентів підтримують анемічну модель даних, яка розумніших людей, ніж я піддаю критиці.
http://martinfowler.com/bliki/AnemicDomainModel.html
(Я знаю, що стаття вище стара, але напрочуд актуальна)
Суть полягає в тому, що AOP-системи тут залишаються, але вони також далеко не ідеальні. Жодна система не є досконалою.