ООП технологии смерти [закрыто]

Я много раз слышал о аспектно-ориентированном программировании, в основном, что это технология «следующего поколения» в программировании, которая собирается «убить» ООП.

Это правильно? ООП умрет или в чем может быть причина?

Каждый раз, когда кто-то говорит вам, что одна программная технология убьет другую или будет доминировать над целым рынком / использованием / аудиторией, запомните это:

Разумная (динамичная, но стабильная) экосистема состоит из множества самых разных видов.

Это означает, что любая новая раскрученная технология пройдет через кривую раскрутки и в конце концов найдет свое конкретное (ые) назначение с течением времени и опытом.

Это также означает, что такая экстремальная концепция, как аспектно-ориентированное программирование, полезна, если она необходима, то есть не всегда и не очень часто из-за подразумеваемых затрат.

Но у него уже есть свое место, как ООПрограммирование, как общее программирование, как функциональное программирование, как процедурное программирование и т. Д.

Заметили ли вы, что языки, которые более широко используются (и пользуются большой популярностью) и широко распространены в реальной жизни, «не чисты»? Это потому, что использование нескольких парадигм делает их более гибкими для изменения контекста во времени, и они занимают больше ниш использования.

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

Парадигмы приходят и уходят, но устаревший код навсегда. Всегда будет поддерживаться код на C ++, поэтому ООП никогда не исчезнет полностью.

Краткий ответ: нет, я так не думаю.

Более длинный ответ: из того, что я понимаю об АОП, это не парадигма программирования сама по себе (как, например, она не заменяет ООП), а скорее дополнение, инструментарий, который помогает вам писать более короткие методы, более простые классы с одной ответственностью и так далее. Но это не заменит ООП.

То, что заменяет или добавляет ООП (по крайней мере частично), это функциональное программирование, которое на самом деле представляет собой другую парадигму программирования (хотя его можно смешивать с ООП, например, на языке программирования Scala ). Он предпочитает неизменные структуры данных и всевозможные необычные функции, которые, как правило, расстраивают разработчиков ООП, особенно когда речь идет о параллелизме.

В настоящее время о ООП говорят меньше, поскольку во многих ситуациях он считается де-факто подходом. АОП никогда не отрывался от земли как любое массовое движение.

Я помню, как впервые услышал об аспектно-ориентированном программировании, сидя в учебнике OOPSLA '97. Они сказали, что тогда убьют ОО. С тех пор OO только превзошло самые смелые ожидания. АОП до сих пор практически не известен и практически не влияет на компьютерную индустрию. Я думаю, что ответ очевиден, что АОП не является убийцей ОО.

Посмотрите на некоторые существующие системы АОП. Они зависят от того, что у вас есть код, написанный в какой-то форме - например, Spring AOP полагается на то, что ваши методы определены в классе. Castle Windsor поддерживает его в C #, который является объектно-ориентированным языком.

Теоретически вы можете перейти от ООП к структурированному программированию и при этом сохранить AOP, но на практике это будет сложно. Легко выделить подклассы, переопределить соответствующий метод для вызова соответствующих фильтров до / после и передать это в процессе внедрения зависимости.

По сравнению с этим чертовски сложно переписать вызовы статических методов для маршрутизации в метод батута, предназначенный для вызова пользовательских фильтров.

Таким образом, с точки зрения общей реализации, АОП требует ООП.

Хотя ООП, конечно, не серебряная пуля, то же самое можно сказать и о АОП. Он поддерживает проектирование на основе компонентов, однако в более грандиозной схеме ваши компоненты являются новыми объектами, а интерфейсы компонентов в основном представляют собой транзакционный список методов, который НЕ является истинным ООП.

Кроме того, AOP и проектирование на основе компонентов поддерживают Anemic Data Model, которую критикуют более умные люди, чем я.

http://martinfowler.com/bliki/AnemicDomainModel.html

(Я знаю, что статья выше старая, но на удивление актуальная)

Суть в том, что системы АОП здесь, чтобы остаться, но они также далеки от совершенства. Ни одна система не идеальна.