TECHNICAL WHITE PAPER:

Producing High-Quality
Software with Aspect-Oriented
Programming
Published: July 2011

PostSharp enables me to achieve things unobtrusively where other

frameworks are large, ungainly, intrusive, slow, and require me to alter my
architecture. As a past user of other AOP systems I am convinced there is
no better system out there right now.
Andrew Matthews
Application Architect
Premier Technologies

CONTENTS
INTRODUCTION.................................................................................... 3
THE TECHNICAL PROBLEM.................................................................. 4
Cross-Cutting Concerns...................................................................... 4
Common Cross-Cutting Concerns .................................................. 4
The Effect of Cross-Cutting Concerns............................................ 5
A Framework for Cross-Cutting Behaviors................................... 6
EXISTING SOLUTIONS..........................................................................7
Dynamic Proxies.....................................................................................7
Functional Programming....................................................................7
Code Generation................................................................................... 8
Meta-Programming.............................................................................. 8
ASPECT-ORIENTED PROGRAMMING: A BETTER SOLUTION............ 9
Overview of AOP................................................................................... 9
The History and Evolution of AOP................................................10
THE BENEFITS OF AOP....................................................................... 12
Lowers Costs by Reducing Lines of Code...................................12
Decreases Defects..............................................................................12
Eases Implementation of Quality Assurance............................13
Improves Maintainability.................................................................13
Improves Teamwork ..........................................................................14
CASE STUDIES..................................................................................... 15
Siemens, Healthcare Industry.........................................................15
FullArmor, IT Industry........................................................................17
POSTSHARP: THE LEADING AOP FRAMEWORK
FOR .NET.............................................................................................. 19
PostSharp Technology.......................................................................19
PostSharp Features............................................................................20
About PostSharp Technologies......................................................21
Featured Customers...........................................................................22
CONCLUSIONS.................................................................................... 23
WORKS CITED..................................................................................... 24
OTHER RESOURCES............................................................................ 25

INTRODUCTION
For years, software engineers have struggled with the question of how
to structure their code in order to maximize reuse and reduce defects.
While traditional object-oriented programming (OOP) provides a solid
framework for code organization, it breaks down when developers must
implement features that cut across the entire system, such as logging and
transaction handling. The usual methods for implementing such crosscutting functionality lead to unnecessary code duplication, an increase in
product bugs, and a decrease in both quality and time to market.
Aspect-Oriented Programming (AOP) adds a high level of reuse to the
traditional OOP framework, with minimal impact on existing code bases.
Aspect-Oriented Programming delivers:
a decrease in development costs and software delivery time;
a reduction in software defects; and
an increase in application maintainability.
The following paper demonstrates these benefits in detail, and
demonstrates how two companies successfully implemented AOP:
Siemens Healthcare using the open-source AspectJ AOP framework; and
FullArmor, using the PostSharp framework.

THE TECHNICAL PROBLEM

Cross-Cutting Concerns

The number of defects in a feature

is proportional to the size of the
component. [Eaddy 2008]

All good programming practice aims to organize software code according

the principle of separation of concerns. Ideally, each software requirement
is implemented in a separate source code artifact. In object-oriented
programming (OOP), the basic unit of organization is the class. Code in
classes is segmented internally by fields (discrete units of information),
methods (discrete units of functionality), and events (discrete units of
reaction). Common families of classes are themselves organized into
namespaces.
The standard OOP approach has proven an excellent model for code
architecture and organization. It falls short, however, when developers
must implement cross-cutting concerns behaviors that are used across
a large number of business requirements, and cannot easily be isolated.

Common Cross-Cutting Concerns

The following cross-cutting concerns are commonly found in business
applications:
1. Logging. Developers often need to see the parameters fed to a method
as it is executing and therefore need to add code to a large number of
places.
2. Security Auditing. Legal requirements and professional standards
frequently demand that a software system write a record of all of its
business transactions to a secure database store. This store may be
audited by an independent auditing agency, a governmental body, or a
court-appointed delegate.
3. Transactions. Modern applications need the ability to roll several
discrete operations into a single unit of work that can be committed
as a whole, or rolled back entirely if any part of the operation fails to
complete.
4. Multithreading. Coping with several threads in an application typically
requires code for thread dispatching and locking of shared
resources a common cross-cutting behavior that has no direct
relation to the underlying business logic.
5. User Interface. Domain objects must typically implement several
services to support rich user interfaces. Change notification and undo/
redo are the most common; each requires code to be added in every
object property.

The Effect of Cross-Cutting Concerns

In a typical OOP approach, cross-cutting behaviors are factored into
separate classes, which are then instantiated and called directly by
business logic code. This forces business logic code to be intimately
aware of these cross-cutting concerns and creates numerous problems for
the architecture and code quality of an OOP application.
1. The number of lines of code increase. Cross-cutting concerns tend
to accumulate: a business logic method that ought to be focused on
calculating shipping for an online order may end up saddled with
boilerplate code dedicated to creating an audit trail, authenticating
the user, notifying the UI that a change has occurred, and executing its
task on a worker thread.
As a feature becomes more scattered
through the code base, the odds
that it will suffer from more defects
increase dramatically. [Eaddy 2008]

2. An enormous amount of code is duplicated, as these boilerplate

calls are often copied and pasted into new methods, which can lead
to duplication of bugs and increases the difficulty of refactoring
the cross-cutting concerns. In other words, OOP applications end up
committing one of the very evils that OOP was designed to prevent:
code duplication.
3. Business logic code becomes entangled with cross-cutting code,
making it harder to find the actual parts of the routine dedicated
to implementing business rules. This makes applications harder to
understand, debug and modify.
4. Business logic code is tightly coupled to cross-cutting concerns. If
a change to transaction handling requires a change to the public
interfaces of the transaction handling component, then potentially all
of the code that uses that component must change as well.
The end result of this approach to cross-cutting concerns is a code
base that is hard to author, hard to maintain, and hard to debug. A study
published in IEEE Transactions on Software Engineering [Eaddy, 2008]
demonstrated that the number of defects in a feature is correlated to two
factors:
1. the number of lines of code implementing that feature; and
2. the scattering of that feature throughout numerous source code
artifacts.

The study, based on the analysis of three widely used opensource projects, also showed that cross-cutting concerns whose
implementation is always very scattered have more defects than
classical business features. Using a rank-order correlation coefficient, the
authors found a strong correlation between a features bug count and
that features diffusion across multiple classes and methods. Crosscutting
concerns in traditional software, noted the researchers, are hard to find,
understand, and work with.

A Framework for Cross-Cutting Behaviors

These shortcomings arent an indictment of the object-oriented paradigm,
which has proven highly successful as a model of code architecture.
Whats needed is an enhancement to this paradigm that enables the
addition of cross-cutting behaviors. Ideally, such an enhancement or
framework would enable:
adding cross-cutting concerns with little or no modification to existing
business logic code;
applying these behaviors to multiple methods, classes, or even
namespaces and assemblies with minimal additional code;
enhancing cross-cutting logic without the need to revise code in the
business object;
eliminating redundant boilerplate code that must be copied from
method to method.

EXISTING SOLUTIONS
Besides AOP, several other frameworks that were originally designed for
other purposes have been recruited to address the problem of crosscutting concerns. Each has its strengths, but because none were originally
designed to address the challenges posed by cross-cutting concerns, each
also possesses significant shortcomings.

Dynamic Proxies

PostSharp enables
me to achieve things
unobtrusively where
other frameworks are
large, ungainly, intrusive,
slow, and require me to
alter my architecture. As
a past user of other AOP
systems I am convinced
there is no better system
out there right now.
Andrew Matthews
Application Architect at
Premier Technologies

A proxy is a common design pattern in which a class operates as

a gateway to one or more other classes. A dynamic proxy is a class
generated on demand by a framework. Because they are generated onthe-fly, dynamic proxies can contain additional dynamic behaviors to
objects, such as logging, or multi-threading in other words, cross-cutting
behaviors.
Dynamic proxies arent flexible enough to implement all types of
cross-cutting behaviors on all types of classes. Dynamic proxies also
require special methods of instantiation, encourage the alteration of the
architecture to conform to the limitations of dynamic proxies, and lack
direct IDE support. While dynamic proxies provide some of the benefits of
AOP, they fall far short of delivering on its full promise.

Functional Programming
Functional programming has become more popular with the addition of
higher-order functions and other functional language constructs to C#. In
a functional paradigm, a function is itself an object, which makes it easy
to compose a family of functions together.
Functional programming has been used with some success to address
some crosscutting concerns such as transaction management or
exception handling. However, this approach has significant drawbacks for
the majority of crosscutting concerns:
1. Developers cannot automatically pass context from the caller to
the aspect code. Tracing of code execution, for example, cannot be
implemented with the functional approach.
2. Developers must modify the code of every function to which they wish
to introduce cross-cutting behavior.

Code Generation
Every developer who has used an IDE is familiar with the code generation
paradigm, in which UI gestures or models, such as data schemas, are
converted into executable code. Visual Studio and the .NET Framework
define several components that attempt to turn such cross-cutting
behaviors as multithreading into a matter of code generation. This is
of only limited effectiveness, however, as it cannot be used to add new
behaviors to existing code.

Meta-Programming
Meta programming, which has been made popular by dynamic languages,
allows programs to change their behavior extensively at both runtime
and build time.
AOP is a specific case of meta-programming. However, AOP operates at a
higher level of abstraction. Meta programming is powerful, but complex
to learn and implement. Developers who have sought to implement
meta-programming as a comprehensive solution to the problem of
cross-cutting have found themselves writing their own aspect-oriented
framework.

ASPECT-ORIENTED PROGRAMMING: A BETTER

SOLUTION
Overview of AOP
The sole purpose of aspect-oriented programming (AOP) is to provide a
cleaner separation of concerns in complex applications, especially where
cross-cutting behavior is concerned.
AOP is necessary because of the complexity gap between our solutions
and our problems. In software, we want to keep our solutions simple, and
our complexity low. Simple solutions are easier to maintain, and easier
to adapt to changing circumstances. In reality, however, our problems are
complex, and dont always yield to simple solutions.
AOP addresses this gap by providing a model that supports implementing
complexity in the simplest way possible. Implementing AOP in a software
project always requires two major stages, irrespective of the AOP platform
used:
1. Encapsulating the cross-cutting concern into a source code artifact
called an aspect. In OOP frameworks, the aspect is generally a
class that expresses the implementation pattern and defines new
behaviors. An aspect describes a program transformation and adds a
new requirement to the code, such as making a method execute in a
transaction.
[Serializable]
public sealed class TransactionScopeAttribute :
OnMethodBoundaryAspect
{
public override void OnEntry(MethodExecutionArgs args)
{
args.MethodExecutionTag = new TransactionScope();
}
public override void OnExit(MethodExecutionArgs args)
{
((TransactionScope)args.MethodExecutionTag).Dispose();
}
public override void OnSuccess(MethodExecutionArgs args)
{
((TransactionScope)args.MethodExecutionTag).Complete();
}
}

2. Applying the aspect to target artifacts in source code. Aspects are

applied to the target artifacts at join points, or points of program
execution. A typical join point is before or after the execution of a
method. Ideally, this application of aspects to join points involves
using some specification such as code annotations, or a configuration
file that involve no or minimal changes to the targeted source code.
Join points can also be designated using pointcuts, which are complex
queries on the underlying code base.
Most AOP frameworks support applying aspects using some form of
declarative programming a form of programming syntax that expresses
a programmers intention without execution logic or control flow. In
Microsofts .NET Framework, declarative programming is implemented
using attributes.
[TransactionScoped]
public int CreateOrder( Order order,
IList<OrderLine> orderLines )
{
}

The History and Evolution of AOP

Early efforts to address the issues of cross-cutting concerns date from
1996. AOP was invented at the Xerox Palo Alto Research Center (PARC) in
1997 when Xerox engineers designed AspectJ, an AOP extension to the
Java language. AspectJ is today the undisputed leader in AOP solutions for
Java.
As AOP grew, the technology behind it matured. The process of weaving
is used to unite the aspects with their join points in the run-time code.
The first AOP platform, AspectJ (see below), relied upon source weaving, in
which a precompiler inserted join point code into the appropriate places
in the source framework prior to compilation. This approach has been
abandoned in favor of compiler extensions or post-compilers.
Aspect orientation was a key factor in the success of the Spring
Framework, which replaced the much more complex J2EE as the de facto
standard for Java enterprise architecture. SpringSource, the company
behind the Spring Framework, has enjoyed enormous commercial success:
after hiring many of the original AspectJ developers, it was acquired
for $400 million USD by VMWare. Since 2003, most Java application
servers have added built-in support for AOP. AOP extensions have been
developed for C++, Ruby, PHP, SAPs ABAP language, and even COBOL.

10

PostSharp is the leading AOP framework in the Microsoft ecosystem. Its

development started in 2006, and the first stable release was reached
in 2007. Several Microsoft products, such as Windows Communication
Framework and ASP.NET MVC, provide a subset of AOP features, but
Microsoft has always been reluctant to use the term aspect-oriented
programming, preferring the terms filters or behaviors instead.
The advent of AOP has also given rise to aspect-oriented software
development (AOSD). The relationship between AOP and AOSD is similar
to the relationship between OOP and object-oriented analysis and design
(OOAD): AOSD brings aspect orientation to the analysis and design
phases of the software development process.

11

THE BENEFITS OF AOP

Lowers Costs by Reducing Lines of Code
The cost of developing software is almost directly proportional to the
number of lines of code produced. Duplicating boilerplate increases the
number of lines of code, and therefore the cost of software development.
Boilerplate code may contribute up to 80% of the source code of
application parts such as the view-model, where concerns such as change
notification, validation, or undo/redo cannot be properly encapsulated.
A 2007 empirical study [Greenwood, 2007] demonstrated that AOP
decreases an applications total lines of code by around 15%. Interestingly,
the advantage of AOP becomes more important as the application
becomes larger. Also, the study was conducted on a rather small project
(under 10,000 lines of code), which suggests that the total benefit may be
even larger.
During its five years of producing and supporting an AOP tool, PostSharp
Technologies has received anecdotal confirmation from its customers
that, as developers gain confidence with AOP technology, its benefits
in terms of reduced lines of code increase. One reason is increased
adaptation: once developers understand the core technology better, it
enables them to apply it more widely across their code bases.

Decreases Defects
As demonstrated by [Eaddy, 2008], the number of defects in a feature
increases with both the number of lines used to implement the feature,
and the degree to which the features code base is scattered across the
system. Aspects address both concerns. Code is reduced and consolidated
by isolating the aspect into a single location. The use of declarative
syntax for applying the aspect to code artifacts eliminates the amount
of boilerplate code that must be injected throughout the system code
that itself may have contained defects, or otherwise required revision in
subsequent versions.
Although aspects can also contain defects, it is much easier to fix a bug
once in the aspect class than in every of the thousands of methods in
which it is applied, as is the case when the behavior is implemented
without AOP.

12

Eases Implementation of Quality Assurance

AOP also helps achieve lower defect counts because it simplifies
authoring code whose sole purpose is to monitor and maintain the
quality of business logic code. A development team that has considered
implementing tracing, performance monitoring, or exception handling
might abandon these plans due to the size of the task, and the high
probability that injecting this code into their source will produce
additional defects. AOP enables such features to be added and removed
from code without affecting the quality or performance of the application.

Improves Maintainability
The initial development of an application represents only a fraction of
its lifetime cost. The applications evolution occurs during maintenance.
As Meir Lehman noticed early, software systems evolve dramatically after
their initial release, and grow in complexity over time [Lehman, 1980].
During the maintenance phase, developers spend as much time reading
code as they do writing it [LaToza, 2006; Ko, 2006]. Analyzing the source
code is necessary in order to understand the changes made by other
members of the team. It also becomes necessary for developers to reeducate themselves on the structure of the system as time progresses,
and their memory of the initial development fades. Turnover is also a
factor: fresh-blooded team members with no prior knowledge of the
system must rely primarily on the source code to educate themselves
about its operation.
Teams that minimize code scattering of cross-cutting concerns make it
easier for developers to find the code affected by a change in a feature.
AOP enables developers to keep business code clean by moving technical
concerns out of business code. A new developer reading source code that
employs AOP doesnt have to differentiate between business logic and
cross-cutting concerns, as the cross-cutting behaviors are neatly isolated
into aspects.
Besides making code easier to read, AOP increases cohesion within
classes. Some studies [Greenwood, 2007] have shown that AOP
applications begin with better cohesion, and maintain more stable
cohesion within their classes over subsequent versions when compared
with traditional OOP applications.

13

Improves Teamwork
When I started to use
PostSharp intensively
in my project, my
code became much
simpler and much
more homogeneous.
At that time, my team
was mainly composed
of junior developers.
Giving them code that
was much simpler that
was just business logic
made it much easier for
them to maintain.

One of the most cited benefits of AOP is improved collaboration within

development teams. Because AOP provides a cleaner separation of
concerns in complex applications, it enables teams to isolate their
architectural patterns from business logic code. This frees more
team members to fuse deep technical knowledge with their intimate
knowledge of the companys business processes.
For example, a developer with expertise in multithreading could
develop multithreading aspects, while another developer with auditing
expertise could develop auditing aspects. Their colleagues can use these
components to add multithreading and auditing to the applications
business logic. Consequently, new team members must study a smaller
code base before starting to be productive.

Pierre-Emmanuel
Dautreppe
Architect at Thales
Information Systems

14

CASE STUDIES
Siemens, Healthcare Industry
Anyone looking for proof that AOP can scale to large applications need
look no further than Siemens Healthcare [Wiese, 2005]. The companys US
division decided to implement AOP on a large-scale hospital information
system being built by 400 developers spread across four countries.
Aspects
Siemens used AOP in four principal areas:

Our ultimate ambition

is to see the entire
range of non-functional
requirements, Quality
of Service monitoring,
authorization and
authentication,
performance monitoring,
distributed caching
and message routing,
implemented using AOP.

Daniel Wiese and

Regine Meunier
Siemens AG
[Wiese, 2005]

Architectural validation. Siemens used pointcuts to tie in code that

validated the multiple layers and separation of concerns required
by their complex Service-Oriented Architecture (SOA). Its validation
aspects ensured during development that each layer could only make
calls to specific other layers (e.g., only the business layer could access
Web Services), and that certain APIs could only be called from specific
layers (e.g., the Java Persistence API could only be accessed from the
data layer).
Caching. Since the SOA was developed by multiple agile programming
teams, each team ended up coding its own solution to common crosscutting concerns. A code review revealed that the SOA contained
multiple, independent implementations for caching of recently used
pages and data objects; some developers rolled their own solutions,
while others employed third party libraries and open source solutions.
The Siemens team centralized all caching behavior into aspects,
greatly reducing the applications code complexity. By implementing
a global caching system, Siemens obtained global control and
monitoring of the applications memory consumption. The use of
aspects also cut down on the extraneous instantiation and invocation
code (so-called glue code) that would have been necessary if the
team had implemented a caching object using traditional OOP.
Auditing. Health care industry applications require strict auditing.
Siemens employed aspects to facilitate auditing. By implementing
aspects that ensured that the auditing framework received an auditing
event after a method was called, Siemens was able to use AOP to
verify that all applicable methods were auditing their execution. These
auditing checks were only used during development, and were easily
disabled during production builds.

15

 Performance monitoring. Finally, Siemens used aspects to trace the

execution time of service calls across its multi-layered system. Aspects
simplified the task of gathering a single set of performance statistics
from which the team could generate a single report. The use of
aspects also made it easier to remove performance monitoring code
from the production release.
Rollout of AOP
Siemens Healthcare skillfully rolled out AOP to its developers in several
stages. Relying on the advice of AOP expert Ron Bodkin, the company
rolled out AOP in four stages:
1. Learning and experimentation;
2. Solving real-world problems;
3. Integration into core development; and
4. Sharing with others.
In stage 1, the company appointed an AOP evangelist who worked closely
with the projects technical leads, and who encouraged individual team
members to experiment and familiarize themselves with aspects.
Stage 2 centered on the rollout of an architectural validation platform
built using AOP. This provided a low-cost way to validate the use of AOP
itself, and to give developers a way to familiarize themselves somewhat
with AOP concepts before having to dive into developing or applying
aspects themselves.
At stage 3, the team decided to implement caching as an initial means
of exposing the application of aspects to developers. It also marked the
companys incorporation of aspects into the global build system. After
this, the project progressed into stage 4, where developers could share
their experiences with aspects, and discuss ways to utilize the technology
going forward.

16

FullArmor, IT Industry

AOP supports the

achievement of a
specific goal of agile
development: to
handle cross-cutting
functionality from an
overall view.
Daniel Wiese and
Regine Meunier
Siemens AG
[Wiese, 2005]

FullArmor (http://www.fullarmor.com/) is a software and Software-as-aService (SaaS) vendor specializing in endpoint management and endpoint
security products for the Windows platform. Its software offerings focus
around scalable management solutions for Windows application delivery
and installation, policy management, profile virtualization, and cloud data
management.
FullArmor maintains a heterogeneous family of software applications
using multiple technologies and deployment environments. Its
application code runs on the server using ASP.NET, as well as in the
browser using Microsoft Silverlight. Further, FullArmors Web server
applications operate both on dedicated physical Web servers as well as
in cloud computing environments, such as Microsofts Windows Azure
and Amazons EC2. Any technology it adds to its software base must be
able to function with high quality and high performance across all these
environments.
FullArmor has integrated PostSharp into three of its key products:
AppPortal, PolicyPortal and ProfilePortal. These three applications and
their shared components comprise approximately 1.2 million lines of
code.
Aspects
FullArmor has used PostSharp to simplify implementation of a range of
cross-cutting features, including:
Tracing. Extensive logging was especially important in phases of the
project, when the target platform (Windows Azure) was still in early
testing phases.
Resource monitoring. FullArmor used aspects to meter consumption
of resources across the system, including devices, users, and network
bandwidth.
Build-time validation. WCF require interfaces and methods to be
annotated with specific custom attributes. An aspect emitted a buildtime error when this protocol was not respected.
Transaction handling. Declarative management of database
transactions.
Exception handling. Application policies required to automatically
retry an operation in response to certain exceptions, or ignore
exceptions that dont indicate a critical failure.

17

 Security. Granting or demanding authorization in response to specific

method calls.
Caching of high-demand data and objects.
Rollout of AOP

[PostSharp] makes it
easier to see whats
relevant, and of course,
that makes [the code]
easier to maintain.
David Gressett
Product Manager and
Chief Architect at
FullArmor

The technology was well received by the companys developers, and the
results have been roundly beneficial. Developers and product managers at
the company report that PostSharp has enabled them to separate crosscutting concerns such as logging and security from their middle tier Web
Services.
Like many large companies, FullArmor uses this easy separation of
concerns to divide its development team according to competencies:
the architecture team focuses on creating aspects that implement
cross-cutting behavior, which the business development team can then
associate with join points across the business layers of FullArmors
application suite.

18

POSTSHARP: THE LEADING AOP FRAMEWORK

FOR .NET
As an approach to software development, aspect-oriented programming
can be implemented through different technologies: source code
weaving, bytecode/MSIL weaving, or dynamic proxies. Many tools are
available on the market for most programming languages. Although all
tools support basic features, they largely differ in their ability to scale to
complex projects and large teams.
Since 2004, PostSharp has distinguished itself by striking a balance
between technical excellence, innovation, and commercial viability. Its
strong focus on usability and reliability, coupled with its ability to scale
to complex projects and large teams, makes it the leading AOP framework
for Microsoft .NET.

PostSharp rocks! And I

mean that as someone
who is doing AOP for
a long while, and has
implemented some not
insignificant parts of
Castle DynamicProxy.
Leaving aside the
amount of power that
it gives you, PostSharp
simplicity is simply
amazing, wow!
Oren Eini (Ayende)
NHibernate, Castle, and
Rhino Mocks contributor

Since 2007, PostSharp has served commercial customers including

Fortune 500 companies in healthcare, finance, and air transportation
sectors as well as educational institutions and government organizations,
worldwide.

PostSharp Technology
PostSharp relies on post-compilation, also called static weaving or MSIL/
bytecode rewriting, which enhances the output of the compiler by
producing a new executable program that includes additional behaviors
added by aspects.
All compilers targetting the .NET platform emit programs expessed in
a binary language called Microsoft Intermediate Instruction Language
(MSIL). MSIL is extensively documented in the ECMA-335 standard
specification, and has proved very stable. Used in some Microsoft products
(e.g. code coverage in Visual Studio Team System, Code Contracts),
post-compiling techniques are fully supported and do not use any
undocumented feature.
Only post-compilation technology supports all of the features required
by robust AOP frameworks high expressiveness, no impact on business
logic, robust aspect composition, build time validation, IDE integration,
and a gentle learning curve.

19

PostSharp Features
High expressiveness
Although most frameworks support simple features, such as method
interception, only a few frameworks including PostSharp implement
the concepts of pointcuts and advices in order to implement most
complex design patterns.
PostSharp allows developers to express aspects using the following
primitives:
Execute code when a method is entered or is exited with success or
failure.
Intercept calls to a method, a field, a property, or an event.
Introduce an interface, a property, or an event to a class.
Add custom attributes to any code element.
Add managed resources to assemblies.
No impact on business logic
Development teams should not be forced to change the architecture of
their existing business logic in order to add AOP behaviors. PostSharp
supports several methods for adding aspects or advices to code:
Declaratively, through custom attributes and multicast custom
attributes. Several elements of code can be targeted in a single line of
code.
Imperatively, by executing C#/LINQ code at build time to evaluate
queries of any complexity over assembly metadata (System.Reflection).
While other frameworks require developers to use special factory
methods instead of constructors, or make most methods virtual, PostSharp
never requires developers to change their code.
Robust aspect composition
An AOP framework must behave in well-documented and predictable
ways when several aspects are applied to the same element of
code especially when those aspects have been developed by two or
more independent teams of developers.
PostSharp has been engineered to guarantee that independently
authored aspects will compose well if they are applied to the same
elements of code.

20

Without robust aspect composition, interactions between aspects become

unpredictable and unmanageable as teams add more of them to the
application.
Build-time validation
The earlier an error is detected, the cheaper it is to fix. PostSharp
validates aspects at build time, and enable developers to write code that
checks that the aspect has been applied to an expected element of code.
There errors are shown in the IDE. Without build-time validation, errors
are discovered in later phases.
IDE integration
There are times where developers need to know all of the targets of a
specific aspect, as well as which aspects are applied to a specific element
of code. PostSharps extensions to Visual Studio help answer these
questions without the need to waste time on studying and debugging
code.
Without IDE integration, developers have to spend more time debugging,
and AOPs promise of greater productivity is lost.
Gentle learning curve
Simple patterns should be simple to implement. Complexity should scale
smoothly as requirements become more involved.
With PostSharp, there is no need to learn advanced concepts such as
pointcuts and advices in order to write a simple aspect. But because these
advanced concepts are implemented, Postsharp enables developers to
compose more complex aspects as their knowledge increases.

About PostSharp Technologies

PostSharp was created by Gael Fraiteur in 2004 as an open-source
project. Gael progressively turned the project into a commercial product
and, in 2009, founded PostSharp Technologies.
PostSharp Technologies builds software for .NET developers who
want to focus more on business logic and creative solutions, and less
on mundane, repetitive tasks. PostSharp Technologies products help
development teams, architects, and managers at industry-leading
companies produce better quality code, and reduce development and
maintenance costs.

21

Featured Customers
PostSharp is used daily by thousands of professional software developers
worldwide.
Finance
Bank of America
BNP Paribas
Deutsche Bank
Societe Generale
Healthcare
Philips
Oracle
Siemens
Technology
AEDS
Intel
NetApp
Thales
SolidWorks
Other
AEDS
eBay
Skanska
Thomson-Reuters
US Airways

22

CONCLUSIONS
Since the foundation of the discipline, the challenges faced by software
engineering have evolved considerably. Whereas the first generation
of computer programmers had to struggle with scarcity of hardware
resources, todays limiting factor is the ability of individuals and teams to
cope with complexity. The capacity to keep source code simple not only
during its inception phase, but during its whole lifetime is one of the
most important keys to success.
As any engineering discipline, software engineering learned that
simplicity is achieved by pursuing a good separation of concerns. A
separation of concerns is what allows designers to componentize
solutions to recurring problems whether in software engineering,
mechanical engineering, electrical and electronic engineering, or
architecture.
Although object-oriented programming (OOP) made significant progress
in this direction, there is still a large category of issues that cannot be
addressed appropriately using traditional programming styles: technical
requirements and others features grouped under the term of crosscutting concerns.
Aspect-oriented programming (AOP) is an extension of OOP and is
specifically designed to address cross-cutting concerns in software
development. AOP enables developers to write a formal expression
of solutions to repeating problems and automatically implement
them rather than manually doing so with conventional programming
techniques. Just as object-oriented programming did not replaced
structure programming, aspect-oriented programming is not a
replacement of OOP but rather an extension of it. AOPs positive impact
on software development is measurable in both controlled studies and
real-world development efforts.
Today, AOP is supported in most languages and platforms. AspectJ, the
reference AOP implementation, is the leading tool for Java. For Microsoft
.NET, PostSharp is by far the most advanced and mature framework, and
has been used commercially for several years by Fortune 500 companies.
The best way for teams to learn AOP is to begin with simple aspects
and add them to non-critical applications. For instance, developers can
use diagnostic aspects during development and remove them from the
production release, all without any impact on code. Then, as developers
become more confident in AOP, they can begin to add more complex
aspects in more critical applications.
By embracing aspect-oriented programming today, engineers are moving
toward software of higher quality and lower complexity.

23

WORKS CITED
[Eaddy, 2008] Eaddy M., Zimmerman T., Sherwood K., Garg V., Murphy
G., Nagappan N., Aho A. (2008). Do Crosscutting Concerns Cause
Defects? IEEE Transactions on Software Engineering, Vol. 34, No. 4,
July/August. Available online at http://citeseerx.ist.psu.edu/viewdoc/
download?doi=10.1.1.164.7117&rep=rep1&type=pdf. Illustrations
reproduced with kind permission of IEEE.
[Greenwood, 2007] Greenwood P., Bartolomei T., Figueiredo E., Dosea
M., Garcia A., Cacho N;. SantAnna C., Soares S., Borba P, Kulesza U.,
Rashid, A. (2007). On the Impact of Aspectual Decompositions on Design
Stability: An Empirical Study. ECOOP 2007 - Object-Oriented Programming,
21st European Conference, Berlin, Germany, July 30 - August 3, 2007,
Proceedings. Available online at http://eprints.comp.lancs.ac.uk/1665/.
[Ko, 2006] Andrew J. Ko, Brad A. Myers, Michael J. Coblenz, and Htet
Htet Aung. An Exploratory Study of How Developers Seek, Relate, and
Collect Relevant Information during Software Maintenance Tasks,
IEEE Transactions on Software Engineering, vol. 32, no. 12, December
2006. Available online at http://faculty.washington.edu/ajko/papers/
Ko2006SeekRelateCollect.pdf
[LaToza, 2006] Thomas D. LaToza , Gina Venolia , Robert DeLine.
Maintaining Mental Models: A Study of Developer Work Habits.
Proceedings of ICSE06, May 2028, 2006. Available online at http://www.
cs.cmu.edu/~tlatoza/Maintaining%20Mental%20Models%20-%20A%20
Study%20of%20Developer%20Work%20Habits.pdf
[Lehman, 1980] Lehman M., 1980. Program, Life-Cycles and the Laws of
Software Evolution. Proceedings of IEEE, 68, 9, pp. 1060-1076
[Wiese, 2005] Wiese D., Meunier R. Large Scale Application of AOP in the
Healthcare Domain: A Case Study. Proceedings of SIGPLAN`05, June 12-15,
2005

24

OTHER RESOURCES
AspectJ http://www.eclipse.org/aspectj/
AspectJ Development Tools http://www.eclipse.org/ajdt/
PostSharp http://www.postsharp.net/

Copyright SharpCrafters s.r.o. 2011. All rights reserved.

In order to respect the copyrights of cited works, please do not diffuse this document without prior written
permission.
PostSharp is a registered trademark of SharpCrafters s.r.o. doing business as PostSharp Technologies.
AspectJ is a trademark of Palo Alto Research Center, Incorporated.
Java and all Java-related trademarks are the property of Sun Microsystems, Inc.
Spring is a trademark of SpringSource, Inc
.NET and Microsoft are trademark of Microsoft Corporation.
SharpCrafters does not have any affiliation with SpringSource, Inc. Sun Microsystems, Inc. or Microsoft Corporation.

25