21-04-2011, 04:38 PM
aop.doc (Size: 113.5 KB / Downloads: 84)
ABSTRACT
In commonly employed code, there are elements that are orthogonal to the primary functionality of the code. These elements, though extraneous to the primary purpose of the code, are vital to its proper execution. Furthermore, they tend to be scattered throughout the system so that they contribute to the complexity of the code. These elements are called aspects. Examples of aspects include processing to support ‘security’, ‘fault-tolerance’ and ‘synchronization’. Aspect-oriented programming (AOP) isolates aspects into separate modules so that the resulting client-code is more purpose-specific, more reusable, and less complex.
AOP introduced to solve crosscutting problems of OOP. AOP is to OOP what OOP was to procedural languages (i.e. C++ to C). OOP does not allow strong implementation reuse. That is each class must either inherit one base class or use delegation (which breaks instance of tests).Another problem with OOP is certain software properties cannot be isolated in a single functional unit, instead they crosscut multiple components. Such crosscutting concerns result in tangled code that is hard to develop and maintain.
In a general sense, the advance made by AOP has been its potential in complimenting OOP to develop an improved system. Certain aspects, like thread synchronization constraints and failure handling, are systemic in nature and present across components, which implies that they get tangled with the main functionality when developers employ conventional OOP approaches alone. AOP successfully ‘captures’ these aspects, and isolates them as a separate entity. In the end, what results is a system that interweaves both OOP and AOP, and which is clearer and more focused on both the primary functionality and the aspects of its performance.
INTRODUCTION
Object-oriented programming (OOP) has been presented as a technology that can fundamentally aid software engineering, because the underlying object model provides a better fit with real domain problems. However most software systems consist of several concerns that crosscut multiple modules. Object-oriented techniques for implementing such concerns result in systems that are invasive to implement, tough to understand, and difficult to evolve. This forces the implementation of those design decisions to be scattered throughout the code, resulting in “tangled” code that is excessively difficult to develop and maintain. The new aspect-oriented programming (AOP) methodology facilitates modularization of crosscutting concerns. Using AOP, you can create implementations that are easier to design, understand, and maintain. Further, AOP promises higher productivity, improved quality, and better ability to implement newer features.
EVOLUTION OF THE SOFTWARE PROCESS
Software design processes and programming languages exist in a mutually supporting relationship. Design processes break a system down into smaller and smaller units. Programming languages provide mechanisms that allow the programmer to define abstractions of system sub-units, and then compose those abstractions in different ways to produce the overall system. A design process and a programming language work well together when the programming language provides abstraction and composition mechanisms that cleanly support the kinds of units the design process breaks the system into.
In the early days of computer science, developers wrote programs by means of direct machine-level coding. Unfortunately, programmers spent more time thinking about a particular machine's instruction set than the problem at hand. Slowly, we migrated to higher-level languages that allowed some abstraction of the underlying machine. Then came structured languages; we could now decompose our problems in terms of the procedures necessary to perform our tasks. However, as complexity grew, we needed better techniques. Object-oriented programming (OOP) let us view a system as a set of collaborating objects. Classes allow us to hide implementation details beneath interfaces. Polymorphism provided a common behavior and interface for related concepts, and allowed more specialized components to change a particular behavior without needing access to the implementation of base concepts.
Programming methodologies and languages define the way we communicate with machines. Each new methodology presents new ways to decompose problems: machine code, machine-independent code, procedures, classes, and so on. Each new methodology allowed a more natural mapping of system requirements to programming constructs. Evolution of these programming methodologies let us create systems with ever increasing complexity. The converse of this fact may be equally true: we allowed the existence of ever more complex systems because these techniques permitted us to deal with that complexity.
Currently, OOP serves as the methodology of choice for most new software development projects. Indeed, OOP has shown its strength when it comes to modeling common behavior. However, as we will see shortly, and as you may have already experienced, OOP does not adequately address behaviors that span over many -- often unrelated -- modules. In contrast, AOP methodology fills this void. AOP quite possibly represents the next big step in the evolution of programming methodologies.