In aspect-oriented software development, cross-cutting concerns are aspects of a program that affect several modules, without the possibility of being encapsulated in any of them. These concerns often cannot be cleanly decomposed from the rest of the system in both the design and implementation, and can result in either scattering (code duplication), tangling (significant dependencies between systems), or both.
For instance, if writing an application for handling medical records, the indexing of such records is a core concern, while logging a history of changes to the record database or user database, or an authentication system, would be cross-cutting concerns since they interact with more parts of the program.
Cross-cutting concerns are parts of a program that rely on or must affect many other parts of the system. They form the basis for the development of aspects. [1] Such cross-cutting concerns do not fit cleanly into object-oriented programming or procedural programming. [2]
Cross-cutting concerns can be directly responsible for tangling, or system inter-dependencies, within a program. Because procedural and functional language constructs consist entirely of procedure calling, there is no semantic through which two goals (the capability to be implemented and the related cross-cutting concern) can be addressed simultaneously. [3] As a result, the code addressing the cross-cutting concern must be scattered, or duplicated, across the various related locations, resulting in a loss of modularity. [2]
Aspect-oriented programming aims to encapsulate cross-cutting concerns into aspects to retain modularity. This allows for the clean isolation and reuse of code addressing the cross-cutting concern. [4] By basing designs on cross-cutting concerns, software engineering benefits can include modularity and simplified maintenance. [5]
Examples of concerns that tend to be cross-cutting include:
In computing, aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. It does so by adding behavior to existing code without modifying the code itself, instead separately specifying which code is modified via a "pointcut" specification, such as "log all function calls when the function's name begins with 'set'". This allows behaviors that are not central to the business logic to be added to a program without cluttering the code core to the functionality.
In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.
Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. The term is sometimes used broadly to refer to "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying" the software, or more specifically "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."
In computer science, a concern is a particular set of information that has an effect on the code of a computer program. A concern can be as general as the details of database interaction or as specific as performing a primitive calculation, depending on the level of conversation between developers and the program being discussed. IBM uses the term concern space to describe the sectioning of conceptual information.
In computer science, separation of concerns is a design principle for separating a computer program into distinct sections. Each section addresses a separate concern, a set of information that affects the code of a computer program. A concern can be as general as "the details of the hardware for an application", or as specific as "the name of which class to instantiate". A program that embodies SoC well is called a modular program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding. Layered designs in information systems are another embodiment of separation of concerns.
In aspect-oriented programming, a pointcut is a set of join points. Pointcut specifies where exactly to apply advice, which allows separation of concerns and helps in modularizing business logic. Pointcuts are often specified using class names or method names, in some cases using regular expressions that match class or method name. Different frameworks support different Pointcut expressions; AspectJ syntax is considered as de facto standard. Frameworks are available for various programming languages like Java, Perl, Ruby, and many more which support pointcut.
AspectJ is an aspect-oriented programming (AOP) extension created at PARC for the Java programming language. It is available in Eclipse Foundation open-source projects, both stand-alone and integrated into Eclipse. AspectJ has become a widely used de facto standard for AOP by emphasizing simplicity and usability for end users. It uses Java-like syntax, and included IDE integrations for displaying crosscutting structure since its initial public release in 2001.
In computer science, a metaobject is an object that manipulates, creates, describes, or implements objects. The object that the metaobject pertains to is called the base object. Some information that a metaobject might define includes the base object's type, interface, class, methods, attributes, parse tree, etc. Metaobjects are examples of the computer science concept of reflection, where a system has access to its own internal structure. Reflection enables a system to essentially rewrite itself on the fly, to alter its own implementation as it executes.
An aspect of a program is a feature linked to many other parts of the program, but which 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.
Gregor Kiczales is an American computer scientist. He is currently a professor of computer science at the University of British Columbia in Vancouver, British Columbia, Canada. He is best known for developing the concept of aspect-oriented programming, and the AspectJ extension to the Java programming language, both of which he designed while working at Xerox PARC. He is also one of the co-authors of the specification for the Common Lisp Object System, and is the author of the book The Art of the Metaobject Protocol, along with Jim Des Rivières and Daniel G. Bobrow.
Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.
AspectC++ is an aspect-oriented extension of C and C++ languages. It has a source-to-source compiler, which translates AspectC++ source code into compilable C++. The compiler is available under the GNU GPL, though some extensions specific to Microsoft Windows are only available through pure-systems GmbH.
In software development, a leaky abstraction is an abstraction that leaks details that it is supposed to abstract away.
In computing, subject-oriented programming is an object-oriented software paradigm in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions ("subjects") of the objects. The term and concepts were first published in September 1993 in a conference paper which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996. As illustrated in that paper, an analogy is made with the contrast between the philosophical views of Plato and Kant with respect to the characteristics of "real" objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird's nor the tax-assessor's additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant's analysis, the same may be true even of characteristics we think of as intrinsic.
An aspect weaver is a metaprogramming utility for aspect-oriented languages designed to take instructions specified by aspects and generate the final implementation code. The weaver integrates aspects into the locations specified by the software as a pre-compilation step. By merging aspects and classes, the weaver generates a woven class.
Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which can contain data and code: data in the form of fields, and code in the form of procedures.
Aspect-Oriented Programming (AOP) presents the principle of the separation of concerns, allowing less interdependence, and more transparency. Thereby, an aspect is a module that encapsulates a crosscutting concern, and it is composed of pointcuts and advice bodies. The interception of an aspect is performed in a join point, and defined inside a pointcut. Whenever the application execution reaches one pointcut, an advice associated with it is executed. However, this implementation does not take into account separation of concerns in distributed settings.
Component-oriented database (CODB) is a way of data administration and programming DBMS's using the paradigm of the component-orientation.
In software engineering, a Library Oriented Architecture (LOA) is a set of principles and methodologies for designing and developing software in the form of reusable software libraries constrained in a specific ontology domain. LOA provides one of the many alternate methodologies that enable the further exposure of software through a service-oriented architecture. Library orientation dictates the ontological boundaries of a library that exposes business functionality through a set of public APIs. Library Oriented Architecture further promotes practices similar to Modular Programming, and encourages the maintenance of internal libraries and modules with independent internal open-source life-cycles. This approach promotes good software engineering principles and patterns such as separation of concerns and designing to interfaces as opposed to implementations.
The composition filters model denotes a modular extension to the conventional object model. It provides a solution for a wide range of problems in the construction of large and complex applications. Most notably, one implementation of composition filters provides an abstraction layer for message-passing systems.
{{cite book}}
: |journal=
ignored (help)