В моем последнем посте мы рассмотрели общую идею пересечения, явления, когда две отдельные задачи (аспекты) программы составлены по-разному, но должны согласовываться друг с другом. . Отдельные композиционные аспекты, вынужденные работать в тандеме друг с другом, могут привести к запутыванию и рассеянию: другими словами, к большому количеству кода WTF. Ваш босс очень усердно скачет на вас, потому что отладка важной функции была настроена в классе тысяч строк, и вы уже пару часов просматривали, пытаясь понять, почему ваша программа не может отслеживать перемещение по дереву файлов. Отчасти это могло быть связано с тем, что код написан плохо. Частично это могло быть ошибочными дизайнерскими решениями. Код, который сложно отлаживать и поддерживать, может быть симптомом пересечения, невидимой силы, которая крутит вашу руку при принятии вторичных решений, соответствующих другим аспектам.
В отрасли вы можете жертвовать одним интересом ради другого, работая с объектно-ориентированной парадигмой. Небольшой фрагмент кода, написанный лаконично, может иметь простую логику, но использование памяти может быть настолько низким, что оплата физического хранилища становится серьезной статьей расходов для вашей компании. В худшем случае инициализация вашей программы занимает секунды, СЕКУНДЫ. Будь то форум или CRM, использующая аналитику для внесения предложений в реальном времени, мы никогда не перестаем беспокоиться о том, как наши аспекты взаимодействуют на независимой основе.
Концепция аспектно-ориентированного программирования (АОП) является результатом попыток объектно-ориентированного программирования (ООП) попытаться создать сплоченные отношения между аспектами. АОП - это сочетание функционального мышления и ООП, направленное на достижение определенного уровня вычислительной рефлексии через метаобъекты, что дает контроль над базовыми структурами / поведением программы.
Язык обобщенных процедур обычно имеет свойства, которые могут быть составлены из:
- компонент, если он может быть четко инкапсулирован в обобщенную процедуру, которая локализована, легко доступна и скомпонована, или
- аспект, если он не может быть четко сформулирован в обобщенной процедуре.
Что такое аспект?
Аспекты, как правило, не являются единицами функциональной декомпозиции системы, а скорее свойствами, которые систематически влияют на производительность или семантику компонентов. Базовая единица модульности в ООП - это класс, тогда как в АОП единицей модульности является аспект.
Аспекты, по сути, представляют собой разделение проблем, и цель АОП состоит в том, чтобы иметь возможность четко разделить эти проблемы, предоставив ткача аспектов. Чтобы создать реферат, который служит механизмом для компоновки аспектов, реализация АОП может создать общую систему со следующим:
- компонентный язык, который выполняет единственную роль компонентов программирования
- ткача аспектов, с помощью которого можно программировать аспекты
- компонентная программа, реализующая аспекты с помощью языков аспектов.
Компоненты содержат фильтры, которые больше не являются явно процедурами, а примитивные циклы написаны таким образом, чтобы их структура цикла была как можно более явной. аспектный язык - это процедурный язык, который обеспечивает простые операции с элементами с существующими отношениями. Давайте вернемся к проблеме, упомянутой в предыдущем посте: мы рассмотрели попытку переписать пример манипулирования пикселями, предоставленный аспектно-ориентированным программированием от Kizcales. Наиболее естественное использование концепций метауровня в Java сопряжено с риском пересечения. Исходная функция манипулировала пикселями черно-белого изображения, начиная с функции, которая создавала новое изображение в конце цикла.
Поговорим о дорогих. Заботясь об оптимизации использования памяти, мы создаем функцию, циклы которой стали трудно читать и со временем становились более дорогостоящими из-за увеличения количества часов, необходимых для обслуживания и отладки. В этом конкретном примере аспекты определены между потоком данных и логикой. Поскольку они не связаны друг с другом, в любом случае мы жертвуем одним доменом ради другого.
Одним из преимуществ ткача аспектов является его разборчивый выбор функций, которыми он хочет заниматься, что снижает накладные расходы, которые обычно связаны с полным отражением. Аспект ткачей может быть составлен по модели, в которой есть:
- выбранные элементы программы, представляющие интерес
- действие, связанное с этими элементами программы
- явная сущность, которая может связать эти 2 аспекта вместе
При повторном рассмотрении переписанной функции источник трудностей при попытке создать функцию, которая была бы как читаемой, так и эффективно использовала память, похоже, кроется в том, как мы пишем наши фильтры.
Переписывая этот фильтр как функцию более высокого порядка, мы достигаем цели написания компонентного языка, в котором циклы теперь максимально явны, а фильтрация больше не записывается как часть функции. Наблюдение за использованием аспекта-ткача с диаграммами позволяет нам реализовать лучшее согласованное сосуществование между потоком данных и логической композицией. По сравнению с диаграммами, наблюдавшимися ранее, анализ двух диаграмм как одной легче обрабатывать, в то время как мы можем успешно реализовать обе конструкции предметной области.
Текущие недостатки АОП
То, что возможности Java ограничивают возможности метапрограммирования, - это тяжелая пилюля. Если бы Java попыталась осуществить неразборчивое рефлексивное программирование - код, который изменяет себя во время выполнения, - при создании новых классов и свойств всегда потребовались бы строгие статические типы. После создания полей / методов тип и часто значение становятся неизменными. Отражение включает в себя разрешение динамического типа, поэтому оптимизация виртуальной машины Java не может быть выполнена, что замедляет отражение.
Отражение позволяет коду выполнять операции, которые не могут быть выполнены Java, такие как доступ к закрытым полям и методам. В результате может оказаться невозможным предоставить доступ для отражения, которое вполне может отображать неисправный код. Истинное отражение имеет склонность открывать члены одного класса другому, что создает конфликт между абстракцией и отражением типа.
Как однажды сказал мой любимый профессор, компьютеры глупы и злонамеренны. Метапрограммирование прекращается, потому что Java AOP не имеет возможности поддерживать контроль доступа. Неспособный соблюдать инкапсуляцию, рефлексивный код рискует нарушить абстракции, что изменит общее поведение кода.
Что именно это означает? Во-первых, впереди у нас много работы. Преодолеть эти проблемы с существующими в настоящее время моделями рефлексии будет чрезвычайно сложно. Может быть, идея метапрограммирования настолько метапрограммирована, холодна и устрашающа, что, возможно, нам нужно, чтобы метапрограммирование было гостеприимным пространством для человеческих соображений, таких как границы. Возможно, нам нужно найти более совместимое пространство для функционального мышления и ООП. Может быть, нам стоит создать переплетение аспектов между отражением и ООП (мета-метапрограммирование ??). В идеале метапрограммирование должно соответствовать тому же языку, с которым оно работает, объекты времени компиляции должны быть первоклассными гражданами, а язык, поддерживающий метапрограммирование, должен быть проще, чем современные современные языки программирования. Попытка создать рациональную основу для метапрограммирования, безусловно, является сложной задачей, но, возможно, нам пора взяться за эту задачу.