Archive for the ‘Code ramblings’ Category

Enums Evolved

Friday, February 19th, 2010

Keying on a particular value is one of the first things we learn in programming.  As time goes on and we learn more advanced concepts, sometimes the little things tend to get lost in the dust and we keep doing things the same way we learned them in grade one.  I recently experienced a little of this pain in a bin packing project I’d been working one.  It all stared with enums, but for the sake of completeness I’m going to start all the way back with strings because that is probably what we all cut our teeth on.

The scenario is this. In a cuboid (box) that is axis aligned we will only ever have six surfaces. In writing code to deal with the cuboid we will be working with these surfaces and we need to know which way that surface is pointing.  Using a simple string approach we might represent it like this…

public class Surface : Rectangle
{
	public static string OrientationBack = "Back";
	public static string OrientationFront = "Front";
	public static string OrientationLeft = "Left";
	public static string OrientationRight = "Right";
	public static string OrientationUp = "Up";
	public static string OrientationDown = "Down";
 
	public string Orientation { get; set; }
}

Now we have a string that tells us the direction that the surface we are working on is pointing. A better approach to the string method would be to put the strings in their own class.

public class Orientation
{
	public static string Back = "Back";
	public static string Front = "Front";
	public static string Left = "Left";
	public static string Right = "Right";
	public static string Up = "Up";
	public static string Down = "Down";	
}
 
public class Surface : Rectangle
{
	public string Orientation { get; set; }
}

The string approach is not optimal for several reasons. 1) We know that the types of orientation are never going to change and so representing orientation as a string is dangerous because if a bad string is used then our logic will not be able to account for it. 2) String comparison while not exactly slow, could be improved by another type. This type of problem would be much better served by an enum instead.

public enum Orientation
{
	Back,
	Front,
	Left,
	Right,
	Up,
	Down	
}
 
public class Surface : Rectangle
{
	public Orientation Orientation { get; set; }
}

This is better because we can guarantee that only our six types will ever be used as an orientation. Plus because enum types are based on integers, comparison operations are fast.

Now we need to do something based on which direction our surface is pointing. This situation appears because our surface is anchored in 3d space by a point which represents its upper left hand corner. We also have its width and height. However in order to do faster collision detection, rendering and ordering we need to translate those values into absolute coordinates for the axis that our surface is sitting on. This means that if we have a surface that is facing left, our depth is going to be on the X axis, our height will be on Z axis, and our width will be Y axis of the 3d container space. This will change depending on which side we are working with. Don’t worry if this doesn’t make sense, it’s simply an example to help illustrate our problem. We are going add these properties to our surface class.

/// <summary>
/// The depth of this plane on the Axis it is aligned to 
/// </summary>
public decimal Z { get; private set; }
 
/// <summary>
/// Top of this surface on the axis it is aligned to
/// </summary>
public decimal Top { get; private set; }
 
/// <summary>
/// Bottom of this surface on the axis it is aligned to
/// </summary>
public decimal Bottom { get; private set; }
 
/// <summary>
/// Left side of this surface on the axis it is aligned to
/// </summary>
public decimal Left { get; private set; }
 
/// <summary>
/// Right side of this surface on the axis it is aligned to
/// </summary>
public decimal Right { get; private set; }

We need to populate those values if our orientation changes or if our point changes. Using the string, or enum method we would end up with something like this.

private void TranslatePoint(Point point)
{
	switch(Orientation)
	{
		case Orientation.Back:
			Z = point.Y;
			Left = point.X;
			Top = point.Z;
			Right = Left - Width;
			Bottom = Top - Height;
			break;
		case Orientation.Front:
			Z = point.Y;
			Left = point.X;
			Top = point.Z;
			Right = Left + Width;
			Bottom = Top - Height;
			break;
		case Orientation.Left:
			Z = point.X;
			Left = point.Y;
			Top = point.Z;
			Right = Left + Width;
			Bottom = Top - Height;
			break;
		case Orientation.Right:
			Z = point.X;
			Left = point.Y;
			Top = point.Z;
			Right = Left - Width;
			Bottom = Top - Height;
			break;
		case Orientation.Up:
			Z = point.Z;
			Left = point.X;
			Top = point.Y;
			Right = Left + Width;
			Bottom = Top + Height;
			break;
		case Orientation.Down:
			Z = point.Z;
			Left = point.X;
			Top = point.Y;
			Right = Left + Width;
			Bottom = Top - Height;
			break;		
	}
}

Wow, that’s a lot of bulk. Now there are probably certain things that could be done to trim that method, but it would still be bulky and hard to read. Plus I am sure that I will be running into the same problem in other places. When you see a method like this you know that it is time to look for refactoring options. There must be a way to move the logic out of this method into the Orientation where it belongs.

There is, and it is called the strategy pattern. Using the strategy pattern we can move the logic into an Orientation class. However because we only want a set amount of values we are going to make some modifications to make it more “enum” like.

Let’s create a new class called Orientation. It will be used both to represent the orientation and to translate global points to that orientation or perform operations that pertain to that orientation.

public class Orientation
{
	private readonly Func<Point, Point> _translator;
	private readonly MathOp _increaseX;
	private readonly MathOp _increaseY;
	private readonly MathOp _increaseZ;
	private readonly Func<Orientation> _flipside;
 
	/// <summary>
	/// Creates a new orientation
	/// </summary>
	/// <param name="translator">Method to translate a global point into a local point</param>
	/// <param name="increaseX">Math operation necessary increase X values</param>
	/// <param name="increaseY">Math operation necessary increase X values</param>
	/// <param name="increaseZ">Math operation necessary increase X values</param>
	/// <param name="flipside">The flipside of this orientation</param>
	private Orientation(Func<Point, Point> translator, 
		MathOp increaseX, 
		MathOp increaseY, 
		MathOp increaseZ,
		Func<Orientation> flipside)
	{
		if (translator == null) throw new ArgumentNullException("translator");
		if (increaseX == null) throw new ArgumentNullException("increaseX");
		if (increaseY == null) throw new ArgumentNullException("increaseY");
		if (increaseZ == null) throw new ArgumentNullException("increaseZ");
		if (flipside == null) throw new ArgumentNullException("flipside");
		_translator = translator;
		_increaseX = increaseX;
		_increaseY = increaseY;
		_increaseZ = increaseZ;
		_flipside = flipside;
	}
 
	/// <summary>
	/// The flipside of this orientation
	/// </summary>
	public Orientation FlipSide
	{
		get { return _flipside(); }
	}
 
	/// <summary>
	/// Translates a global point to this orientation
	/// </summary>
	/// <param name="point"></param>
	/// <returns></returns>
	public Point Translate(Point point)
	{
		return _translator(point);
	}
 
	public MathOp IncreaseX
	{
		get { return _increaseX; }
	}
 
	public MathOp IncreaseY
	{
		get { return _increaseY; }
	}
 
	public MathOp IncreaseZ
	{
		get { return _increaseZ; }
	}
}

Notice how the constructor is private so that we can control its instantiation. We are also making use of delegates in the constructor so we can easily create logic in the constructor without having to resort to making a subclass for each different orientation. If you notice that we havn’t defined the MathOp class anywhere, that’s because it’s simply this exact same pattern repeated except for a math operation.

Next we are going to infuse the strategy pattern with enum like functionality through the use of static fields.

public class Orientation
{
	public static Orientation Back = new Orientation(
		p => new Point(p.X, p.Z, p.Y), 
		MathOp.Subtract, 
		MathOp.Subtract, 
		MathOp.Subtract, 
		() => Front);
	public static Orientation Front = new Orientation(
		p => new Point(p.X, p.Z, p.Y), 
		MathOp.Add, 
		MathOp.Subtract, 
		MathOp.Add, 
		() => Back);
	public static Orientation Left = new Orientation(
		p => new Point(p.Y, p.Z, p.X), 
		MathOp.Add, 
		MathOp.Subtract, 
		MathOp.Subtract, 
		() => Right);
	public static Orientation Right = new Orientation(
		p => new Point(p.Y, p.Z, p.X), 
		MathOp.Subtract, 
		MathOp.Subtract, 
		MathOp.Add, 
		() => Left);
	public static Orientation Up = new Orientation(
		p => new Point(p.X, p.Y, p.Z), 
		MathOp.Add, 
		MathOp.Add, 
		MathOp.Add, 
		() => Down);
	public static Orientation Down = new Orientation(
		p => new Point(p.X, p.Y, p.Z), 
		MathOp.Add, 
		MathOp.Subtract, 
		MathOp.Subtract, 
		() => Up);

We have now ended up with an enum-like class that incorporates so much more functionality. Assigning an orientation to a variable is as simple as…

surface.Orientation = Orientation.Up;

Comparison works the same way.

if(Orientation == Orientation.Up)
	//do something

The only thing that we are lacking is the ability to switch on our Orientation class, but with the new functionality we shouldn’t need to. Just look at what our bulky “TranslatePoint” method has turned into.

private void TranslatePoint(Point point)
{
	Point translated = Orientation.Translate(point);
	Z = translated.Z;
	Left = translated.X;
	Top = translated.Y;
	Right = Orientation.IncreaseX.Calculate(Left, Width);
	Bottom = Orientation.IncreaseY.Calculate(Top, Height);
}

By applying an appropriate pattern we have made our code more readable, less bulky and insured that it has a stable growth plan.

Remember when refactoring don’t forget the simple things.

Dependency Injection in WPF Bindings

Monday, December 1st, 2008

Creating clean testable code is one of the major challenges when creating complicated, composite user interfaces.  To help with this a variety of patterns have cropped up including MVC, MVP, and most notably for WPF the MVVM pattern.   These patterns work fine for the most part at least until your view gets a little bit too complicated.  What is a programmer supposed to do with the added complexity?  You should be separating common logic out into self contained controls, each with their own view models.  This is easier said then done, as you need to make sure that you provide view models for each of the controls your view implements.  While this is probably the more accepted way of doing things, it leads to a lot of code noise and increased complexity when writing tests for your main view model.

There is another way and you can get there by using the Markup Extensions that are available to exend WPF.  Because I’m a bit to lazy to create my own custom binding extension, I used one that I found here http://www.hardcodet.net/2008/04/wpf-custom-binding-class .  This fellow has already explored custom bindings and has created an easy to use base class for creating and manipulating custom WPF bindings.

With this class in place it is a fairly trivial operation to create a databinding class that utilizes your favorite dependency injector.  For this sample I am using StructureMap.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
    /// <summary>
    /// Binds to a dependency injected object
    /// </summary>
    public class DIBinding : BindingDecoratorBase
    {
        /// <summary>
        /// The type we are looking for
        /// </summary>
        public Type Type { get; set; }
 
        /// <summary>
        /// The key if applicable
        /// </summary>
        public string Key { get; set; }
 
        public override object ProvideValue(IServiceProvider provider)
        {
            //use DI to get the value
            if(Type == null)
                throw new InvalidOperationException("You must specify a type for this binding");
 
            Source = String.IsNullOrEmpty(Key) ? ObjectFactory.GetInstance(Type) : ObjectFactory.GetNamedInstance(Type, Key);
 
            return base.ProvideValue(provider);
        }
    }

Once we have created this binding helper we can use it in any xaml file provided that we include the proper namespaces of course.

1
<TreeView ItemsSource="{DataBinding:DIBinding Type=MainNav:IMainNavigationMenu, Path=MenuItems}" />

Use of dependency injection in your xaml files should be limited to where it is appropriate.  Of course it is not appropriate to do you whole application in this manner, but for certain controls it can lead to a much cleaner more testable view model for rest of your code.

Serialization bites again.

Thursday, October 9th, 2008

I’ve been back working on NHibernate.Remote for the last week since I finished some of the more urgent updates for the company where I’m working.  I’ve come to the sad realization that the path I’ve been treading with the initial NHibernate.Remote codebase just won’t cut it for several reasons.

1) NHibernate needs a session factory.  You just can’t operate remotely or locally without a session factory.  Initially my goal was to transfer the required factory information across the wire to the remote client. However this approach doesn’t work very well as SessionFactory information is deeply nested and not conducive to serialization.  So I’ve opted for the next best thing which is to create an identical session factory on both ends of the wire.  That way both the server and the client can be aware of Entities, Collections and Proxies.  The only thing that the remote session factory does not get is a connection string, so it cannot be used to open a direct database connection.  So far this has been working fairly well and has enabled me to get both Criteria queries and NHibernate.Linq queries working over the wire.

2) That was the good news, now for the bad news.  The remote client simply needs to be aware of the entities that it is holding.  That means that every time an entity or a collection comes in over the wire it needs to affect the persistence context.  If this can be implemented flushing the remote session will become much easier.  I thought that the ObjectGraphWalker that I had created would be up to this task but once again I appear to be mistaken.   One of the requirements  I need is that I need to be able to replace an entity as I walk the object graph.  Let me explain further.  In a local NHibernate session if you query an object, change some properties and then query that object again, NHibernate is smart enough to detect that it already has that entity and will return to you the original changed object.  I need to do that remotely, thus the requirement for substituting objects when I walk an incoming graph.  That is simply impractical with the way that the ObjectGraphWalker works.

So I’m back to needing custom access to the inner workings of a serializer. I’ve tried to hack my way into the NetDataContractSerializer but with little success.  Surely my requirement is neither original or unique and Microsoft would do well to provide more open access to their serialization techniques.  Most likely I’ll just have to use reflector to extract the functionality that I need.  Sigh.

HashSet to the rescue

Wednesday, June 25th, 2008

This week while working on NHibernate.Remote I came across an unusual performance problem.  When sending objects back and forth across the wire, I need to walk the object graph to ensure that things like lazy sessions are updated to correspond to the local ISession.  This is done through a combination of reflection and serialization (which is reflection anyways).  I should be doing this in a custom serializer but MS has made it so incredibly difficult to extend the XmlObjectSerializer that I’ve just decided to walk the graph after deserialization. While walking the object graph I need to store the references of objects I’ve already probed so that I don’t end up with an infine loop due to circular references.  Anyways due to a combination of poor code and some optimization oversight I ended up with just over 15000 objects in my reference list which was just using a standard generic List<object>.   A query for ~1000 records was taking over 4 seconds to complete which simply was not acceptable.  At first I thought that it was just an unavoidable consequence of using so much reflection.  However in a bid to speed things up a little I ran the Ants analyzer on it.  To my complete surprise it was the reference list that was slowing things down.  After looking at my code I identified the week points in my code and optimized the amount of references I was storing in the list eventually ending up with ~4000 entries for my 1000 record query.   The query was now completing in well under a second.

Even though the problem was solved it still bugged me.  I had just mitigated the problem by reducing the amount of entries rather than making the lookup faster.  So the same slowdown would be experienced as someone increased the amount of records returned by their queries.

Then today  I unexpectedly ran across the solution to my problems.  The HashSet<T>.  This is a collection that is new in the .Net 3.5 framework and is contained in the System.Core library.  It uses indexing to help speed up the Contains() method and boy is it fast. Because it is a set and not a list it cannot contain the same element twice, but that happens to be just perfect for my needs.  After implementing the same buggy code using the HashSet<object> instead of List<object>  my 1000 record query took ~0.5 of a second to complete.  That’s even faster than the optimized code was using List<object>.   Of course optimizing is still important, but I gained an important speed boost due to the use of this exciting new collection.  I know this will definitely find its way into some of my other projects too.

High hopes, and crushed dreams

Tuesday, April 15th, 2008

I think that there is a fundamental law of the universe at work in programming, and it goes something like this.  “Everything is much harder than it looks at first glance.”

My troubles started when I decided that I needed a custom serializer or at least some serialization extension points in order to better optimize the way that NHibernate.Remote transmits its data.  Currently I am letting the NetDataContractSerializer do all the work and I am using reflection later to walk the object graph and do things such as update the session on lazy items and synchronize objects that are supposed to be reference equal.  All in all it’s a lofty goal.

I began to dig into the serialization mechanism to look for extension points in the NetDataContractSerializer.  To my dismay though, most of the applicable classes were internal, sealed or didn’t contain anything usefull.  I thought I was out of luck until I came upon Serialization surrogates.  In effect this allows you to attach a serializer/deserializer to an object type (or all object types) and push part of the serialization process through your own code.  This was really close to what I wanted as it would allow me to examine individual objects as they were being serialized and deserialized.  This would mean no more walking the object graph and should net a nice little performance gain.  Yes? actuall NO.

After wiring in some loose code to extract object data and such I tested it to see if it would actually work.  It actually did work, amazing.  Then I fired up Ants to see what the performance was, and to my dismay it was 26x slower.  This was for sure not acceptable as I was hoping to see a performance gain.  I did a more detailed analysis using Ants to figure out where my code went wrong and to my amazement it was not in my code but in MS’s NetDataContractSerializer.  The  SurrogateDataContract which is responsible for getting the data to my custom SerializationSurrogate is incredibly slow, and it doesn’t look as if there is anything I can do about it.

Sigh… So I’m back to square one here.  Leave the reflection code in place as it is already working,  write my own serializer from scratch (Bleh), or start emitting IL code to hack the NetDataContractSerializer?