Suppose you want to create an enum that offers the facility to combine several values together such as the RegexOptions of the Regex class or the CommandBehavior of the ExecuteReader from the ADO.NET Command object.
The example below describes an enum that can be used to indicate which tires need to be changed in the pit stop.
public enum TireChangingOptions
{
FrontLeft,
FrontRight,
BackLeft,
BackRight
}
public void ChangeTires(TireChangingOptions Options)
{
//test which tires to change
}
Now, with this code we won't make it. First of all, when using an enum as basis to combine several possibilities together, then we need to indicate this by the [Flags] attribute. So this would result into:
[Flags]
public enum TireChangingOptions
{
FrontLeft,
FrontRight,
BackLeft,
BackRight
}
This will allow us to combine values like this:
TireChangingOptions tcOptions = TireChangingOptions.BackLeft | TireChangingOptions.FrontRight;
There's still one problem with this enum; you probably know that the underlying type of an enum is an int. So, in the current syntax, FrontLeft will get by default the value 0, FrontRight the value 1, BackLeft = 2 and BackRight = 3. This is not something we can use when we want to combine these values together. In the current setup we can never detect the difference between BackRight (which equals to 3) and between FrontRight | BackLeft (which sums up to 1 + 2 = 3 as well)
So we need to specify values for our enum parts. Just be aware that you shouldn't use the value 0, because it won't allow you to use the OR operator. So, this brings us to:
[Flags]
public enum TireChangingOptions
{
FrontLeft = 1,
FrontRight = 2,
BackLeft = 4,
BackRight = 8
}
In order to test which values have been set you need to use the binary AND operator which is &. So the example code looks like:
public void ChangeTires(TireChangingOptions Options)
{
//Test which tires to change
if ((Options & TireChangingOptions.FrontLeft) == TireChangingOptions.FrontLeft)
//TODO: add code
if ((Options & TireChangingOptions.FrontRight) == TireChangingOptions.FrontRight)
//TODO: add code
if ((Options & TireChangingOptions.BackLeft) == TireChangingOptions.BackLeft)
//TODO: add code
if ((Options & TireChangingOptions.BackRight) == TireChangingOptions.BackRight)
//TODO: add code
}
For a very good study on the subject of enums go to this blog
- Erik
This morning I was browsing through the features of the new Enterprise Library. When reading an article in the December’s issue of .NET magazine, I stumbled upon a term AOP or Aspect Oriented Programming and that it would make it in one of the future versions of the Enterprise Library.
Curious as I am, I started to look for some more info and found some very good stuff (as usual) on the Net. Here are some good links:
Basically, AOP is all about writing less code and reducing the scattering of your “technical code”. In your application, we could say, we have some business code and some technical code. The first which actually implement your problem domain and the latter is merely to assist this. Typically logging and transactions are good examples of such technical code.
In most of today’s applications, you will see a lot of this technical code scattered amongst all the different parts of the application, keeping it hard to maintain and difficult to configure. This technical code implements a concern that can’t be pinpointed to just one class or part of the application, it should cover what we call a cross cutting concern.
The goal of AOP is to model these cross cutting concerns in such a way, that they could be “forgotten about it”. Ok, this is not totally true, but the idea is to focus on the problem domain and to implement it in your business code. The fact that we need logging in our application is without any doubt, however, we shouldn’t be writing to code for it when tackling the business problem. Instead we should write at specific points like; “here we need logging” and carry on, we call these join points in AOP.
So, we need to package the implementations of these cross cutting concerns in individual aspects, that are complete and self describing. These aspects then need to be weaved into the main application. Theoretically there are two possibilities here, which are static weaving end dynamic weaving. The most known example of static weaving is AspectJ and weaves the aspect code into the main program at compile time. It uses a pre-compiler to weave the code into place. For .NET you can look at AspectC# and Loom.NET
Dynamic weaving applies the aspects at runtime, in fact COM+ is a very good example of this. It provides cross-cutting services like transaction management, connection pooling, etc to the registered COM objects. It uses interception as a base for implementing this and providing the objects living inside COM+ with a given context. If COM+ were to have an extensible way of adding new custom aspects to its list of service then it would truly be an AOP framework.
Conclusion
Well, since I’m just starting off myself in this programming paradigm, I’m surely not to guy to offer you any well balanced thoughts on AOP. The only advice I can give you, is read some articles or papers about it and keep up with today’s programming industry.