Saturday 29 October 2011

OO Enums

I was looking for feedback on my previous post about Enum Visitors.

I was literally inundated with feedback from 1 person:

The Article lacks the why

and

Why would i want to do this if an enum is:

  • What I know
  • Easy to understand
  • Performs well

Clearly this looks like many reasons not to fuss.

There are even more things in favour of the enum like the bitwise operations.

I welcome this criticism because I, much like other programmers often fixate on a certain solution or implementation and forget what the original problem was or even if there really was one and why we wanted to solve it in the first place.

I do not advocate to add complex patterns to your code base just for the sake of using the pattern.

And even though I think a part of me  was trying to solve a problem that perhaps isn’t such a big problem but to see if I could come up with something decent.

So lets look at the reasons NOT to use my method.

It’s added complexity for some.

Enums are FAST, and I mean VERY fast, got say 1-5 enums even with the most tweaked dictionary the switch statement will be much faster.

You may run into a scenario where you have 100ds of enums where the performance goes the other way, but in this case you probably wont be using enums anyway.

And I can possibly think of scenarios like high speed logging, where you might want to think a bit more about how your performance may be affected

That’s about the last i will say about the performance, because I feel that unless you are running VERY tight loops with 1000ds of iterations this will be a fraction of your programs execution time for either of these methods.

Many people reduce OO/Layers or abstractions to gain performance and there are times you simply have no other choice, however I feel that favouring ease of use and maintenance over performance where acceptable is often a better choice.

But either way there might be situations I will be the first to say DON’T use this way.

But lets look at why this might be a good idea.

Having a switch statement you may introduce many pathways through your code known as Cyclomatic Complexity.

This means it becomes hard to test the function entirely without stimulating it with ALL the options the enumeration provides.

If we invert this operation and instead of switching over an enum we use a visitor or strategy map it is a little bit like the Hollywood Principle (Don’t call us, We’ll call you)

In fact if you think about it this is one of those really cool and catchy terminologies, but often it is described in a way that is hard to understand.

And I don’t see in the description that they refer to this or the visitor even though i feel this is appropriate.

I have read MANY places that people constantly refer to OCP (Open-Close principle), and how the switch statement violates this.

And  I somewhat agree, when you switch around many conditions, as soon as 1 or more of those conditions change the code that is switching around them needs change.

This means the system must change and cannot just be extended by adding a strategy class or a visitor method.

However you still need to make a change the only difference is where. If you have added switch logic over the same enum on many places then changing an enum changes the code in all those places.

The difference between the visitor/strategy and the switch statement is that with the switch statement it is YOU the caller or consumer that needs change. YOU need to decide which type you are dealing with and write the if-else or switch logic to control the flow of the code, you may do this MANY times and this increases your responsibility of future change instead of just being concerned of the business logic of your program.

Using a strategy or visitor you simply call the Accept method or execute on the strategy and can only focus on the business logic you should be concerned of.

The flow of execution is inverted and this is the important concept to understand.

Of course this is just one abstraction, the decision is made somewhere and when the enum changes so does the somewhere. So you may have a situation where you only need to make a code decision for your application in ONE place.

Take this example:

public enum MessageType
{
Unknown,
Message,
Success,
Highlight,
Error
}

Say this is just a simple enumeration to use in our code to log certain status messages now we could switch around the code like this:

Would result in code such as this:

void LogMessageWithEnum(MessageType messageType, string message)
{
switch (messageType)
{
case MessageType.Message:
Console.ForegroundColor = ConsoleColor.White;
break;

case MessageType.Success:
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine(message);
Console.ForegroundColor = ConsoleColor.White;
break;

case MessageType.Highlight:
Console.ForegroundColor = ConsoleColor.Yellow;
Console.WriteLine(message);
Console.ForegroundColor = ConsoleColor.White;
break;

case MessageType.Error:
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine(message);
Console.ForegroundColor = ConsoleColor.White;
break;
}

If this is converted to a visitor:

public class MessageTypeVisitor
{
public MessageTypeVisitor(string message, bool newLine)
{
this.Message = message;
this.NewLine = newLine;
}

void LogMessage(string message)
{
if (NewLine)
Console.WriteLine(this.Message);
else
Console.Write(this.Message);
}



[EnumVisitor(MessageType.Message)]
public void LogMessage()
{
Console.ForegroundColor = ConsoleColor.White;
Console.WriteLine(this.Message);
}

[EnumVisitor(MessageType.Success)]
public void LogSuccess()
{
Console.ForegroundColor = ConsoleColor.Green;
Console.WriteLine(this.Message);
Console.ForegroundColor = ConsoleColor.White;
}

[EnumVisitor(MessageType.Highlight)]
public void LogHighlight()
{
Console.ForegroundColor = ConsoleColor.Yellow;
Console.WriteLine(this.Message);
Console.ForegroundColor = ConsoleColor.White;
}

[EnumVisitor(MessageType.Error)]
public void LogError()
{
Console.ForegroundColor = ConsoleColor.Red;
Console.WriteLine(this.Message);
Console.ForegroundColor = ConsoleColor.White;
}

public string Message { get; set; }

public bool NewLine { get; set; }
}

Using this will become as follows:

messageType.Accept(new MessageTypeVisitor(formattedMessage, newLine));

Now your code becomes more open-close, you could be asking an abstract factory or IoC container to provide you with a MessageTypeVisitor meaning your code would never have to change its logic based on what enumeration was provided.

Of course all this really is, is an abstraction, I can create a function LogMessageWithEnum and be done with it. My code that uses the LogMessageWithEnum is shielded from the underlying switch and decision making, and in some cases this may be the only place I use this enum, My code may not use this enum for any other reason. So by simply using a function I have created a sufficient abstraction and remain closer to Open-Close to my consuming code.

The problem really comes in when I have these same switch statements scattered around making the same or very similar decisions around this enumeration, in this case I haven't sufficiently abstracted myself from the use of this.

In conclusion

I wanted to create something for those times where you are looking for this type of solution. But not replace the enum or usage of this sparingly or in a way that makes sense. As always let your own common sense guide your solution.

Friday 28 October 2011

My Hammers

 

If all you have is a hammer, everything starts looking like a nail

 

image image
* Image source * Image source

Have you ever felt like certain patterns/classes/libraries just work in EVERY situation or solves any problem that is REALLY HARD.

These certainly feel like hammers and in fact golden hammers in a world full of nails.

Of course you should always question yourself if it is on any extreme, and that if you are really trying to hit screws with hammers then maybe its time to think of another approach.

In any case I will talk about the tools that works for me in so many situations and that are most of the time, EASIER to understand, FASTER to write and more maintainable.

In either case I’m sure to never leave home without them

So let me jump in in no particular order…

#1. The Builder

image This feels appropriate to start with not just for the name but it takes care of all those complex creations you may have in an application.

If you find yourself saying:

I don’t want to use DI because it makes my object creation more complex.

Then you might want to consider using a builder.

The builder may also reduce or replace singletons in your application.

The builder pattern as described by Wikipedia:

The builder pattern is an object creation software design pattern. The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects. Often, the builder pattern is used to build products in accordance to the composite pattern, a structural pattern.

You can certainly read the documentation to an example implementation, but in fact just like all patterns they will vary greatly in their implementation and in my opinion they have added additional layers of complexity to this than what is needed.

The most important thing here is (abstract steps of construction).

So for instance just to follow on the concept of abstraction, in the documentation there is a use of a director, which is something you DON’T HAVE TO DO.

I found this post on stackoverflow with the exact same question.

So this really is just an abstraction to the steps of construction of an object and can be:

  1. A method.
  2. A Class with one method
  3. A Base class and many steps of construction, with many child builders
  4. A Class accepting other Builders as constructor arguments
  5. A Class with fluent API to specify some optional or additional properties.
  6. A Builder can be 1:1 or 1:* meaning being able to construct more than one type of object.

The organization of this logic is therefore determined to what makes sense and it depends on the size and complexity of construction, so I would extract more builders and base classes as construction complexity increases, the same rules as any class keep responsibilities only as big as they need to be.

With that said I will just pick an average example.

Say we had a controller which had a bunch of dependencies that needed creation, we could create the following builder:

public class ControllerBuilder
{
public Controller Build()
{
return new Controller(BuildDao());
}

protected virtual Dao BuildDao()
{
return new Dao(this.BuildContext());
}

protected virtual IDataContext BuildContext()
{
return new LinqDataContext();
}
}

And in our unit test project I can construct the exact same controller for my unit test, however modify override a small part to replace with the appropriate dependencies for in memory tests.

public class MemoryControllerBuilder : ControllerBuilder
{
protected override IDataContext BuildContext()
{
return new MemoryDataContext();
}
}

Usage of this then becomes something like this:

public class WebPage
{
public void Page1_Load()
{
Controller controller = new ControllerBuilder().Build();
}

public void Page2_Load()
{
Controller controller = new ControllerBuilder().Build();
}
}

The builder aids you application in achieving better Inversion of control, Dependency injection and still keeping things explicit

#2. The Dictionary

image The dictionary is probably one of the most powerful, flexible, high performing hammer/tool in modern languages like C# that is like sunlight, vital but often overlooked or taken for granted.

In the past many older languages never had dictionaries out of the box and third party vendors went out their way to create implementations of dictionaries, today in C# this is available out the box for FREE.

Many remember hash tables. And since generics in C# this became the generic Dictionary. They are in fact the same thing underneath.

Each object provides a GetHashCode() which is a unique key that the dictionary uses to sort objects for fast lookup.

The dictionary truly can turn many things into a nail, try to imagine wherever you used a dictionary for something what the alternative would be. You would find that the alternative is much less elegant and performing.

The dictionary makes many patterns SO EASY they seem trivial at worst for example:

Service Locators

Factories

Mappers

Also anything needing lookup, Dictionaries are great for:

Loose-Coupling and supporting principles like Open-Close.

The Dictionary can be responsible for many new powerful patterns.

If you browse to Wikipedia and look up Design Patterns you won’t really notice the mapper pattern really being documented even though in fact it should be.

By simply combining strategy and factory using a dictionary we can create a very powerful pattern to map objects from strings/enumerations or any constant type to abstractions and therefore following a whole bunch of good principles like Open-Close and so many other and yet this seems so simple we hardly think about it at all.

Example:

Say we have an enumeration as follows: (Simply indicating an environment that is configured)

public enum Environment
{
Production,
Test
}

The example is extremely trivial to keep things simple and short but imagine a situation where this can grow to a much larger size.

We would normally code this as follows:

switch (environment)
{
case Environment.Production:
return @"c:\production";
case Environment.Test:
return @"c:\test";
default:
throw new Exception("Invalid environment");
}

Once again the example is very simple, but pretend that we could be doing much more complicated things depending on environment.

If we wanted to convert this to the strategy pattern (also called provider). We would declare a provider like this:

public abstract class EnvironmentPathProvider
{
public abstract string GetPathName();
}

Then we would create the different strategies like this:

public class ProductionEnvironmentPathProvider : EnvironmentPathProvider
{
public override string GetPathName()
{
return @"c:\production";
}
}

public class TestEnvironmentPathProvider : EnvironmentPathProvider
{
public override string GetPathName()
{
return @"c:\test";
}
}

And now our usage looks like this:

public Dictionary<Environment, EnvironmentPathProvider> BuildProviderMap()
{
var map = new Dictionary<Environment, EnvironmentPathProvider>();
map.Add(Environment.Production, new ProductionEnvironmentPathProvider());
map.Add(Environment.Test, new TestEnvironmentPathProvider());
return map;
}

public string GetFileLocation(Environment environment)
{
EnvironmentPathProvider provider = null;
if (BuildProviderMap().TryGetValue(environment, out provider))
{
return provider.GetPathName();
}
throw new Exception("Invalid environment");
}

We added more code which seems unnecessary, but it is only in this initial example and after this our code will not increase much and we are much more open close and extensible in our program. And we are combining  more than one good OO principles.

So next time you use a dictionary spare a thought for this awesome hammer.

#3. The Lambda

image It will be hard to say how useful this really is and give enough reasons to say why.

I will try and say that when the books on design patterns were written they were written to take most languages into consideration. For the danger of not being hunted down by old elitists with long beards I will refrain from mentioning a language or specific. But I do believe that lambdas sometimes replaces the need for certain patterns.

From MDSN:

A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.

The article provided also gives some great examples.

Linq would also not be possible without this. This also makes new patterns emerge like IoC, Factories, Mappers etc.

How to use this is probably beyond the scope of this article, it simply is that useful, this certainly is more than just a golden hammer but more like a platinum hammer in my toolbox.

 

#4. The Interface

image The ultimate abstraction.

There is no better way to isolate yourself from concrete implementations of code.

Interfaces also makes multiple inheritance possible without some of the trouble associated with it.

An interface contains only the signatures of methods, properties, events or indexers. A class or struct that implements the interface must implement the members of the interface that are specified in the interface definition.

From MDSN:

An interface contains only the signatures of methods, properties, events or indexers. A class or struct that implements the interface must implement the members of the interface that are specified in the interface definition.

Principles like ISP (Interface segregation principle) are worth noting and keeping in mind when designing interfaces.

So next time you are dealing with an external dependency or API library consider protecting yourself against the volatility of change and use interfaces.

#5. Linq

image Language integrated query:

Language Integrated Query (LINQ, pronounced "link") is a
Microsoft .NET Framework component that adds native data querying capabilities to .NET languages, although ports exist for Java[1], PHP and JavaScript.

I’d have to admit that this has increasingly become a more popular tool for me over time.

At first we saw linq as a great tool for querying databases particularly due to its type safety. But also for the provider support (one query can work on a number of platforms).

However from how this has grown for me over time and from what i see that can be done with this just within the language on objects, Lists, PLINQ.

Suddenly it just seems like so much effort to write

foreach (BaseController controller in controllers)
{
...
}

vs.

controllers.ForEach(controller => .. )

So that concludes the list of hammers for now, these might change over time but for now I consider them vital tools.

Thursday 20 October 2011

C# Enum Visitor Pattern

I have not written for a while and in fact it is too long and shameful.

I was working on a bunch of ideas but haven’t been able to get it finished, but i want to start now and focus on some patterns for a while and starting with this:

Suppose we have an enum like this:

public enum LifeCycle
{
    Transient,
    ThreadLocal,
    Singleton
}

Now lets just pretend that we want to make various decisions and perform operations or tasks based on which enum has been selected.
In this particular case i want to construct an object that represents the enum. 
 
You may think this is a factory pattern or strategy/factory map so therefore I can construct a strategy and make it visitible by adding an Accept method.
 
The problem with this as i mentioned is that the operation could really be anything and I want something generic that could be used for any enum.
 

I wanted to see the validity of this approach and what others may think so I wanted feedback from the community, so see my question on stackoverflow.

And also I didn’t want the user of this code to go and create a strategy class for each type.

Now lets say I define a set of values (in this case classes)

public class LifeCycleBase { }
public class SingletonLifeCycle : LifeCycleBase { }
public class ThreadLocalLifeCycle : LifeCycleBase { }
public class TransientLifeCycle : LifeCycleBase { }

I want these returned for each condition would normally result in code like this:

switch (lifeCycle)
{
case LifeCycle.Singleton:
return new SingletonLifeCycle();
case LifeCycle.ThreadLocal:
return new ThreadLocalLifeCycle();
case LifeCycle.Transient:
return new TransientLifeCycle();
default:
throw new Exception("Unsupported LifeCycle: " + lifeCycle.ToString());
}

So we might in one case have an operation that returns a class like a strategy per enum, in another case we might want to just return a string representing the type or any other arbitrary operation.

In creating a more OO solution you could use a strategy class as mentioned, but this would result in a consumer creating a class for each enumeration and then for each different strategy based on the enumeration.

The second solution is to use a visitor pattern. This is more appropriate than the strategies as one class groups together a collection of operators using double dispatch.

In either case this results in quite a bit of plumbing.

So what I want is:

      1. A solution that is VERY easy to implement
      2. Requires minimal plumbing
      3. Is very generic and reusable
      4. Performs well
      5. Is type safe

I thought I would like to be using something like this:

EnumVisitorHelper.Accept<LifeCycleBase>(lifeCycle, new MyLifeCycleEnumVisitor());

And that THIS, would be very easy to use and much better from an OO perspective.

The visitor loos like this:

public class MyLifeCycleEnumVisitor
{
public override LifeCycleBase VisitTransientLifeCycle()
{
return new TransientLifeCycle();
}

public override LifeCycleBase VisitSingletonLifeCycle()
{
return new SingletonLifeCycle();
}

public override LifeCycleBase VisitThreadLocalLifeCycle()
{
return new ThreadLocalLifeCycle();
}
}

This is the helper:

public class EnumVisitorHelper
{
public static T Accept<T>(System.Enum theEnum, object visitor)
{
var methodName = string.Format("Visit{0}{1}", theEnum.ToString(), theEnum.GetType().Name);
foreach (var method in visitor.GetType().GetMethods())
{
bool acceptable = method.Name == methodName;

if (acceptable) acceptable = typeof(T).IsAssignableFrom(method.ReturnType);
if (acceptable)
{
return (T)method.Invoke(visitor, new object[] { });
}
}
throw new Exception("Method not found");
}
}

It will use reflection to double-dispatch onto the visitor based on the name of the enumeration.

This is certainly

  1. Easy to use
  2. Minimal Plumbing
  3. Good OO
  4. Is Generic and Reusable

BUT ITS NOT:

The best performing

Not 100% type safe as an enumeration may change and could break some visitors.

You will also notice the lack of a Visitible, this is more of a double-dispatch pattern than visitor but if we wont get too technical it still works.

So I thought how to fix these problems and first i thought to create a Visitible interface:

public interface IVisitible
{
T Accept<T>(object visitor);
}

And then I wanted a factory to construct a Visitible:

public static class EnumVisitibleFactory
{
public static IVisitible Create(System.Enum enumeration)
{
return new EnumVisitible(enumeration);
}
}

But in order to double dispatch I can either automatically map back to the enum name, but this would not be type safe. So I thought of using attributes instead:

public class EnumVisitor : Attribute
{
public object Enumeration { get; set; }

public EnumVisitor(object enumeration)
{
this.Enumeration = enumeration;
}
}

Now my visitor can be decorated as follows:

public abstract class MyLifeCicleVisitorBase<T>
{
[EnumVisitor(LifeCycle.Transient)]
public abstract T VisitTransientLifeCycle();
[EnumVisitor(LifeCycle.Singleton)]
public abstract T VisitSingletonLifeCycle();
[EnumVisitor(LifeCycle.ThreadLocal)]
public abstract T VisitThreadLocalLifeCycle();
}

Now an attribute decides which is the visitor method also the method essentially can now be your name of choice. Lastly this gives you some type safety that you will get compiler help once there is a enum breaking change.

This is the concrete Visitible:

public class EnumVisitible : IVisitible
{
private object _enumeration;
public EnumVisitible(System.Enum enumeration)
{
this._enumeration = enumeration;
}

private static readonly Dictionary<Type, Dictionary<object, MethodWrapper>> _staticMap =
new Dictionary<Type, Dictionary<object, MethodWrapper>>();
private static readonly object _syncLock = new object();

MethodWrapper Map(object visitor)
{
foreach (var method in visitor.GetType().GetMethods())
{
var attributes = method.GetCustomAttributes(typeof(EnumVisitor), true);
if (attributes.Length > 0)
{
var attr = (EnumVisitor)attributes[0];
if (attr.Enumeration.Equals(this._enumeration))
{
return new MethodWrapper(method);
}
}
}
throw new Exception(string.Format("Enumeration: {0} not mapped", this._enumeration.ToString()));
}

MethodWrapper GetCachedMap(object visitor)
{
var type = visitor.GetType();
Dictionary<object, MethodWrapper> enumToMetodInfoMap = null;
MethodWrapper mi = null;

bool found = false;

lock (_syncLock)
{
found = _staticMap.TryGetValue(type, out enumToMetodInfoMap);
if (!found)
{
enumToMetodInfoMap = new Dictionary<object, MethodWrapper>();
_staticMap[type] = enumToMetodInfoMap;
}
}

lock (_syncLock)
{
found = enumToMetodInfoMap.TryGetValue(this._enumeration, out mi);
}
if (!found)
{
mi = Map(visitor);
lock (_syncLock)
{
enumToMetodInfoMap[this._enumeration] = mi;
}
}
return mi;

}

#region IVisitible Members

public T Accept<T>(object visitor)
{
var method = this.GetCachedMap(visitor);
var parameters = method.GetParameters();
var inParameters = new List<object>();
foreach (var parameter in parameters)
{
object inParam = null;
if (parameter.ParameterType.IsAssignableFrom(typeof(IVisitible)))
{
inParam = this;
}
inParameters.Add(inParam);
}
return (T)method.Invoke(visitor, inParameters.ToArray());
}

#endregion
}

public class MethodWrapper
{
private MethodInfo _methodInfo;
private IMethodInvoker _invoker;

public ParameterInfo[] GetParameters()
{
return this._methodInfo.GetParameters();
}

public MethodWrapper(MethodInfo methodInfo)
{
this._methodInfo = methodInfo;
this._invoker = new MethodInvoker(methodInfo);
}

internal object Invoke(object visitor, object[] p)
{
return this._invoker.Invoke(visitor, p);
}
}

Now I can use it like this:

EnumVisitibleFactory.Create(lifeCycle).Accept<LifeCycleBase>(new MyLifeCycleEnumVisitor())

EDIT: I can further improve things with an extension:

public static class EnumExtensions
{
public static IVisitible CreateVisitible(this Enum value)
{
return EnumVisitibleFactory.Create(value);
}

public static TResult Accept<TResult>(this Enum value, object visitor)
{
return EnumVisitibleFactory.Create(value).Accept<TResult>(visitor);
}
}

Then the usage becomes EVEN NICER:

LifeCycle.Singleton.Accept<LifeCycleBase>(new MyLifeCycleEnumVisitor());

This is now more OO, generic fast (as its using a static dictionary).