Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Аспект программы — это функциональность, связанная со многими другими частями программы, но не относящаяся к её основной задаче. Аспект пронизывает основные области программы, тем самым нарушая принцип разделения ответственности, который стремится к инкапсуляции несвязанных функций. Например, код логирования может пронизывать множество модулей, однако аспект логирования должен быть отделен от функциональных задач модуля, который он пронизывает. Изоляция таких аспектов, как логирование и сохранение данных, от бизнес-логики является основой парадигмы аспекто-ориентированного программирования (AOP). Аспекто-ориентация не ограничивается программированием, поскольку она полезна для выявления, анализа, отслеживания и модульного представления задач на этапах сбора требований, спецификации и проектирования. Аспекты могут быть многомерными, позволяя как функциональному, так и нефункциональному поведению пронизывать любые другие задачи, а не только сопоставлять нефункциональные требования с функциональными. Одна из точек зрения на аспекто-ориентированную разработку программного обеспечения заключается в том, что каждая основная функция программы, основная задача (бизнес-логика) или сквозная задача (дополнительные функции) является аспектом, и, объединяя их (процесс, также называемый композицией), в конечном итоге создается целое из отдельных аспектов. Этот подход известен как чистое аспекто-ориентированное программирование, но гибридные подходы более распространены. Функциональные задачи могут пронизывать нефункциональные или функциональные задачи (например, потребность в дополнительных функциях может снизить мобильность). Унифицированный подход к представлению и композиции, аналогичный чистому подходу в AOP, называется многомерным представлением.
An aspect of a program is a feature linked to many other parts of the program, but is not related to the program's primary function. An aspect crosscuts the program's core concerns, therefore violating its separation of concerns that tries to encapsulate unrelated functions. For example, logging code can crosscut many modules, yet the aspect of logging should be separate from the functional concerns of the module it cross cuts. Isolating such aspects as logging and persistence from business logic is at the core of the aspect oriented programming (AOP) paradigm. Aspect orientation is not limited to programming since it is useful to identify, analyse, trace and modularise concerns through requirements elicitation, specification, and design. Aspects can be multi dimensional by allowing both functional and non functional behaviour to crosscut any other concerns, instead of just mapping non functional concerns to functional requirements. One view of aspect oriented software development is that every major feature of the program, core concern (business logic), or cross cutting concern (additional features), is an aspect, and by weaving them together (a process also called composition), one finally produces a whole out of the separate aspects. This approach is known as pure aspect programming, but hybrid approaches are more common. It is possible for functional concerns to crosscut non functional or functional concerns (e. g., the need for more features harms mobility). A uniform approach to representation and composition, similar to the pure approach in AOP, is termed multidimensional representation.