Introduction to AspectJ

1. Introduction to AspectJ Part 2 The Limits of Conventional SoC Advanced Separation of Concerns Aspect Oriented Programming AspectJ

2. The Limits of Conventional SoC • in 1997, OO developers who read Meyer, could have been excused for thinking thatthey were achieving the full benefits ofSoC, because they were being told that OO decomposition (s/w construction) delivered the following: • Reusability • Extendibility • Understandability • this claim was based on the fact that OO s/w construction satisfied all 15 conditions of modularity

3. How OBJECT-ORIENTED DECOMPOSITION supports the 15 conditions 5 rules 5 criteria Direct Mapping Modular Decomposability Few Interfaces Modular Composability Explicit Interfaces Modular Continuity Information Hiding Modular Protection Small Interfaces (weak coupling) Modular Understandability Linguistic Modular Units principle Self-Documentation principle 5 principles Uniform Access principle Key: directly supported neutral or N/A Open-Closed principle Single Choice principle

4. The Limits of Conventional SoC • but does OO decomposition really deliver understandability, reusability, extendibility? • does it really satisfy all 15 conditions of modularity? • to answer this question, let's look at the concept of 'Concern' as presented in Ramnivas Laddad’s book: AspectJ in Action • what is a s/w system concern? and what types of concern are there? • to answer this, let's first look at concerns in the context of building a house • it is possible to identify two types of concern: primary concerns and secondary concerns

5. The Limits of Conventional SoC • primary concerns involve making good choices for the core features of the house i.e. the design of • foundation • height of walls • pitch of roof • location of rooms • size of rooms • secondary concerns involve making good choices for the features that are shared by many of the core elements of the house e.g. the design of • electrical wiring • plumbing

6. The Limits of Conventional SoC • now let's move to s/w development, and let's define a concern as follows: CONCERN = a specific requirement or consideration that must be addressed in order to satisfy the overall system goal • S/W System = the realization of a set of concerns • in s/w development, it is also possible to identify primary concernsand secondary concerns. • primary concerns • these cover the primary, core functionality • e.g. in a business application, they cover the business logic • they are located in an application’s core modules • so let’s call them CORE CONCERNS

7. The Limits of Conventional SoC secondary concerns these are system-wide concerns i.e. concerns that are common to many of the core modules e.g.: storage management data persistence performance multithread safety administration transaction integrity resource pooling error checking logging policy enforcement security let’s call them CROSSCUTTING CONCERNS since they cut across multiple core modules/subsystems. e.g. the data persistence concern crosscuts every stateful object the logging concern affects every significant module

8. The Limits of Conventional SoC • how well are these two types of concern modularized when using OO decomposition? • if a good job is done of assigning responsibilities to objects, and of deciding how objects should collaborate, then OO decomposition: • achieves good modularization of core concerns • but is not so good at modularizingcross-cutting concerns… in fact, it fails to modularize them. • the symptoms of this non-modularization can be broadly classified into two categories: • code SCATTERING • code TANGLING (S&T = abbreviation for Scattering and Tangling)

9. The Limits of Conventional SoC • code scattering occurs when a single concern is implemented in multiple modules • since crosscutting concerns, by definition, cut across many modules, their implementations are scatteredover all those modules. • e.g. in a system using a DB, performance concerns may affect all the modules accessing the DB • there are two types of code scattering: duplicate code blocks andcomplementary code blocks • duplicate code blocks • characterized by repeated code of nearly identical nature • e.g implementation of authorization often leads to the addition of nearly identical code to multiple modules • e.g. in the banking system in the diagram on the next page, many modules in the system must embed the code to ensure that only authorized users access the service

10. Accounting Internet Banking Check for authorized access Teller Operations Customer Care code implementing the authorization concern is scattered throughout several modules

11. The Limits of Conventional SoC complementary code blocks • the second kind of scattering happens when several modules implement complementary parts of a concern • in a conventionally implemented access control system the following might happen: • authentication is performed in one module • authenticated user is passed to modules that need authorization • and then those modules will perform the required authorization all these pieces must be carved to fit together perfectly, much like puzzle pieces, to implement the functionality (see diagram)

12. A Authenticate Users Access Control B A B C D Authorization Concern Permission Management C Session Management D code scattering caused by the need to place complementary code blocks in multiple modules to implement some functionality

13. The Limits of Conventional SoC • code tanglingoccurs whena moduleis implemented thathandles multiple concerns simultaneously Business Logic Security Logging Persistence A module managing multiple concerns

14. public class SomeBusinessClass extends OtherBusinessClass { ... Core data members ... Other data members, to support peripheral concens ... e.g. Log stream ... e.g. Cache update status ..Override methods in the base class public void someOperation1( OperationInformation info ) { ... Ensure authorization ... Ensure info satisfies contracts ... Lock the object to ensure thread-safety ... Ensure cache is up to date ... Log start of operation ... PERFORM THE CORE OPERATION ... Log completion of operation ... Unlock the object } ... More operations similar to above, addressing multiple cross-cutting concerns // Methods to support peripheral services public void save( <persistence storage parameters> ) { … } public void load( <persistence storage parameters> ) { ... } } Consider a skeletal implementation of a class encapsulating a number of cohesive core concerns

15. The Limits of Conventional SoC • method SomeBusinessClass.someOperation1contains code for authorization, contract enforcement, optimization (caching), and logging, all tangled up with the core operation. • SomeBusinessClass itself, contains operations for persistence management as well as support for logging and cache management, which tangles them with the core state and behaviour of the module. • the log stream and cache update status do not seem to be related to the core requirements of this class: they are in the class only to support the system-level requirements of the caching and logging concerns.

16. Class with normal implementation of factorial function public class Functions { public long factorial ( int n ) { long result = 0L; if ( n == 0 ) { result = 1; } else { result = n * factorial ( n – 1 ); } return result; } }

17. public class Functions { private Map cache = new HashMap(); public long factorial ( int n ) { long result = 0L; Integer cachedResult = ( Integer ) cache.get( new Integer( n ) ); if (cachedResult != null ) { result = cachedResult.longValue(); } elseif ( n == 0 ) { result = 1; } else { result = n * factorial ( n – 1 ); cache.put( new Integer( n ), new Long( result ) ); } return result; } } More Efficient Class Uses caching to improve performance Class Implements Two Concerns (wich are tangled): Core concern: computation of the factorial of a number. Secondary concern: making the computation performant.

18. The Limits of Conventional SoC • and here is the tenuous link (of which I spoke in part 1, when we looked at Dijkstra ), between the concept ofgoto and the subject of these presentations: • tangling has been described as the modern day equivalent ofspaghetti code • instead of gotosdistracting from the main flow of control in a segment of code, lines of code implementing cross-cutting concerns, distract from the main flow of control implementing the core concerns. • negative effects of S & T: • poor traceability • lower code reuse • lower productivity • poor quality • difficult evolution

19. The Limits of Conventional SoC So OO decomposition • is good at modularizing (separating) core concerns but fails to modularize cross-cutting concerns: these are scattered across several modules and their implementations tangled between themselves and with core concerns • delivers understandability, extendibility and reusability of the implementation of core concerns but not of cross-cutting concerns • satisifies Meyer’s 15 conditions for core concerns but not for cross-cutting concerns

20. OO DECOMPOSITION OF CROSSCUTTING CONCERNS Direct Mapping scattering Modular Decomposability S&T Few Interfaces Modular Composability S&T Explicit Interfaces Modular Continuity scattering Information Hiding scattering Modular Protection Small Interfaces (weak coupling) Modular Understandability S&T Linguistic Modular Units principle Key: not supported due to reason neutral or N/A Self-Documentation principle Uniform Access principle Open-Closed principle scattering Single Choice principle scattering

21. The Limits of Conventional SoC • we saw earlier how important the OCP is because in many ways it is at the heart of OO design. • Unfortunately, although it is possible to design the modules of an OO s/w system so that they are both OPEN and CLOSED against changes to and/or extensions of core concerns OO systems are NOT closed against the addition of cross-cutting concerns. • when the implementation of cross-cutting concerns are added to a system, system-wide changes have to be made. • so back in 1997, mainstream SoC techniques were not delivering understandability, extendibility and reusabilityin full, because they were unable to separatecrosscutting concerns.