Buzzword Buster – AOP


Aspect Oriented Programming (AOP) is a programming paradigm where each application can focus on its primary functions and core concerns by encouraging greater modularity and increasing separation of cross-cutting concerns (such as logging and authentication).


In any real-world applications, when you’re writing code to address the problem domain (say, booking an order) you might need to address other concerns such as:

  • persistence – writing to the database for example
  • transaction handling – defining transaction scope and setting rollback strategy, etc.
  • security – user authentication for example
  • logging – for auditing and debugging

So effectively you’re mixing multiple domains with fine-grained intersections and likely to end up with:

  • tangled code – making it more difficult to work out what the code is doing to address the core concern
  • boilerplate code at every intersection point – introducing duplicated code and increasing the size of the code base and the blast radius of any change that are not related to the problem domain, e.g. changing the persistence media..

AOP aims to address these problems by separating cross-cutting concerns into single units called aspects, each aspect encapsulates behaviours that affect multiple classes into reusable modules.

Parting thoughts..

As far as I can think of, the only drawback of AOP is that you no longer see all the behaviours of your class when you open it and it requires knowledge of the whole system to know what else are happening under the cover. Which interestingly, is the flip side of the same coin because you employ AOP when you don’t want to deal with cross-cutting concerns all the time!

One of the ways to mitigate this problem is to build up a culture in your team and standardise how AOP is implemented so that everyone is on the same page and there are few surprises.


PostSharp provides a lightweight AOP framework for the .Net platform and is establishing itself as the de facto standard much like the way AspectJ has done for Java.

Good old days!

My good friend Raj sent me some pictures he took from Chinese new year 2006, and really brought back some nice memories from the days gone by!

As some of you may know, I performed on stage for Chinese new year in 2006 in Trafalgar Square, in the middle of the freezing cold in Feb! It was definitely one of the best experiences I ever had, the adrenalin rush of performing in front of thousands of people was simply amazing! So, to show you what I’m on about, here’s some pictures ;-)

63_430x330 CNY%20290106%20-%20%2814%29

CNY%20290106%20-%20%2820%29 DSC00032

DSC00033 DSC00036

100_0163030406 (2)

and don’t we all love a poser lol


Adoption problems with WPF

I was having an email conversation with a friend on WPF yesterday and he suggested putting it into a blog post after I went on and on for a bit (sorry Raj!).

Having spent some time learning Silverlight (which is a subset of WPF for the web, Microsoft’s equivalent of Flash) I have really come to like the new programming model in WPF and how easily it allows you to do things that were simply impossible to do in WinForms (ever tried to put a rounded corner to a rectangle anyone?).

To those not familiar with WPF, it’s powered by DirectX so you get hardware acceleration and can use features such as transparency, gradients and transformations. Its programming model enables clear separation of the UI from business logics because you now have to build your UI using a declarative language – XAML (Extensible Application Markup Language).

The event model has also been revamped and it’s now possible to ‘route’ an event so it originates from one element but is raised by another. WPF supports several types of routed events, but Silverlight only allows bubbled events which cascades up the containment hierarchy from deeply nested element to its containers.

Why is Declarative UI better?

Whilst declarative UI is something of a shock to the system to most of us (web developers not included!) it actually makes perfect sense because it helps solve one of the biggest problems in UI development – business logic embedded in UI.

A declarative UI makes it harder to write business logic into the UI because you’re writing less code. However, it’s not about separation of tiers, but separation of concerns, so when you find problems there is a smaller blast radius! Which again, all comes down to loose coupling – the same thing people are trying to achieve with IoC and Dependency Inversion from a dependency point of view.

So all’s well with WPF and industry veterans are all raving about it (there’s a number of shows on DotNetRocks alone which covers WPF and Declarative UI) so why is there still a distinct lack of real-world apps out there? Besides the odd project on CodePlex like Family Show and Scott Hanselman’s BabySmash, I haven’t found too many examples out there (it’s a shame Photology‘s dead.. :-( )


I think there are two main reasons why a lot of people are still not adopting WPF, neither has anything to do with the technology itself which is like a fancy new drug which makes you never want to go back! And there are plenty of industry support both in terms of third party support (well known UI controls producers like teleriks, infragistics already offer numerous UI packages for WPF and Silverlight) and backing from the industry veterans.

1. it’s still fairly young

Having only made it into the core .Net platform since .Net 3.0 (nov 2006) it is still fairly new to most developers considering that most people are still happy using .Net 2.0 (I know this is definitely true in the banking/enterprise world!) which equates to:

  • a lack of existing expertise in the field, making it hard for would-be adopters because it adds to the cost of adoption in time and expense regardless of their strategy to acquire these expertise, i.e. new recruit vs. training existing staffs
  • an additional risk with adopting WPF because you have to first migrate your platform to .Net 3.0, which, should be minimal because it’s really just an add-on to the .Net 2.0 framework. But then again, “why fix what’s not broken?”

2. it’s only a viable option for new developments

Because WPF introduces a completely new set of technologies and a new programming model to boot, it’ll require significant time and effort to convert an existing UI application. This means WPF is only worth considering for new developments.

The future:

As with all things Microsoft, there’s a strong focus on enterprise users and I’m sure their representatives would continue to make a push for their partners to adopt WPF and dare I say once they decide to jump on board MS would have a problem stopping them from coming back for more! Yup, WPF is that good!

With the .Net platform going strong as ever (mentioned in 44% of developer jobs posted in the UK in the last 6 months), the universal adoption of WPF as the de facto standard for developing UI application should only be a matter of time. Given the risk-adverse nature of large enterprises (who, given their size and financial muscles, have more say on technology trends than anyone else), it’s no surprise to me that WPF has not really caught on, but as more and more enterprises jump on the WPF bandwagon they’ll in turn increase the size of the talent pool available to others and really set the ball rolling.

Further reading:


Prism: patterns & practices Composite Application Guidance for WPF and Silverlight site

Imperative vs. Declarative Languages

Following my previous post on multi-language (polyglot) and multi-paradigm (poly-paradigm) development, I thought I’d continue on the same thread for a little and do some comparisons on some of the popular types of programming languages.


An imperative programming language such as C# or Java allows you to specify step-by-step how a problem should be solved using a series of statements which change a program’s state. It’s important to remember that whilst Object Oriented Programming is how we are all taught to do imperative programming these days, it’s not the only way – C and other procedural languages are also imperative languages.

A declarative programming language on the other hand, is a higher level programming language which allows you to express what you want without specifying how to get it. SQL is probably the most widely used declarative language today and in SQL you don’t tell the query analyzer how to go about fetching the data, you just state what data you want to retrieve and it takes care of the rest. It’s also worth nothing that

How they compare:

The benefit of declarative language is that it separates the process of stating a problem from the process of solving it. It’s essentially an extension of design by contract where producers of the declarative input describe what they need and how they need it, allowing producers of the declarative program to determine the best way to get it.

Approximating this in an imperative language is possible because at heart, everything is imperative. The challenge in doing so is that an imperative program operating on declarative input must be prepared to check pre and post conditions and have a plan to deal with every eventuality!

Declarative languages allows for greater extensibility, agility and productivity. Think how quickly you can create a table, input some data and then get the data back in some form or another in SQL and then imagine the time and effort it’d require if you were to implement these in C#.

However, as a user of a declarative language, you have limited or no control over how your inputs are dealt with and therefore have no option but to mitigate the impact of any imperfections/bugs in the underlying language and rely on the providers of the declarative language to address the issues.

Less is MORE

Just finished watching an interesting seminar video by the guys from Object Mentor (a consultant company founded by Robert C Martin, the father of agile development) at:

The video is about an hour long and covered a large number of topics around using different languages (polyglot) and different programming paradigms (poly-paradigm) to simplify and speed up the software development process. The main thing I took away from this was:

“Less code is better, so less code is more. With less code, all your problems become smaller, be it maintenance, testing or performance.”

which most developers would agree I’m sure, after all, one of the reasons we refractor our code is so we end up with less code.

For young developers like myself, we have come into software development in an era dominated by the object oriented paradigm and a small handful of mainstream OO languages like C++, C# and Java. So for me at least, it’s refreshing to see how other paradigms and languages can be used in conjunction with those I’m familiar with to achieve:

  • greater productivity from the developers
  • more agile and extensible solution


If you don’t have the time to watch the video (or simply not interested enough to do so!) then hopefully the list of key points I’ve compiled together would at least give you some idea what it’s all about:

  • There’s no silver bullet in software development
  • OO paradigm not always the best solution for the problem
  • Statically-typed languages (C#, C++, Java, etc.) are compiled for greater speed and efficiency at the cost of lowering productivity
  • Dynamically-typed language (ruby, python, JavaScript, etc.) are interpreted for greater extensibility, agility and productivity at the cost of lowering runtime performance
  • Ola Bini‘s Three layers – Domain layer (Domain Specific Languages), Dynamic layer (JRuby, etc.) and Stable layer (Java, C#, etc.)
  • Scripting languages increases pace of development
  • Aspect-oriented programming makes it easier to deal with cross-cutting concerns
  • Functional programming makes concurrency easier, because:
    • functions are side-effect free and stateless
    • nothing to synchronize, so no locks, semaphores, mutexes
  • Functional programming is cloud computing friendly
  • Functional languages and DSLs are more declarative than imperative
  • Scala is cool!
  • Advantages of the polyglot and poly-paradigm approach are:
    • able to use the best tool for a particular job
    • minimize the amount of code required and keep them closer to the domain
    • better decoupling between components
  • Disadvantages of this approach are:
    • multiple tools, languages, libraries to manage and learn
    • need to manage the different metadata models and overhead of calls between languages
  • It’s nothing new! For example, web developers often have to work in different paradigms and languages on a website
  • Higher end-user expectations and tighter schedules are driving the popularity of higher level languages such as functional and scripting languages
  • Developers have to deal context switching between different languages, so as the application grows larger and more complex, you have to start partitioning the teams (should be second nature to those working in the enterprise world!)

Parting thoughts..

As the presenter stated several times throughout, polyglot and poly-paradigm programming (PPP) has all been done before (despite now being mentioned with unfamiliar terminologies), and I certainly see a lot of familiarity of it in my line of work where in a typical 3-tiered application you’d have:

  • the data access layer using SQL (relational paradigm)
  • the business layer written in C#/Java or other OO languages
  • the UI can be in any number of different languages or paradigms depending on its form (HTML/CSS/Java/C#, etc.)

and numerous scripting languages (Perl, for example) are also used in various places (hell, after all, there are over 5000 applications being actively used within Credit Suisse alone!).

Watching this video has helped me identify with what I already know and put names (polyglot, poly-paradigm) to familiar faces (which is why jargon are important and I keep blogging about buzzwords :-P ), watch it, and see if it can help you too.

Further readings:

Ola Bini’s blog post on writing different layers of code in different languages