Using the Generic Flyweight Architecture in Visual Basic .NET

Encoding QR in Visual Basic .NET Using the Generic Flyweight Architecture

Using the generic Flyweight pattern implementation isn t complicated and is well suited in a component situation. What is important about using the generic Flyweight pattern implementation is that it should be hidden in the context of a builder. Let s say that the following interface and implementations are instance types that a client is interested in: public interface ITestFlyweight { string Identifier { get; } } class TestFlyweightA : ITestFlyweight { public String Identifier { get { return "TestFlyweightA"; } } } class TestFlyweightB : ITestFlyweight { public String Identifier { get { return "TestFlyweightB"; } } }

The interface ITestFlyweight has a single property, Identifier, that retrieves a property value. In your own solutions, the interface could have as many methods or properties as needed, but the interface needs to be immutable. Additionally, an interface doesn t need to be used; instead you could employ a base class. Or if desired, in the declaration of FlyweightFactory you can include the type object, which allows the referencing of any object instance. In the example, TestFlyweightA and TestFlyweightB both implement the ITestFlyweight interface and a rudimentary implementation of the property Identifier. The following Builder class illustrates a complete Flyweight pattern implementation: class FlyweightBuilder { public static ITestFlyweight Transformation( object desc) { if( String.Compare( (string)desc, "TestFlyweightA") == 0) { return new TestFlyweightA(); } else if( String.Compare( (string)desc, "TestFlyweightB") == 0) { return new TestFlyweightB(); } throw new NotSupportedException(); } public static IFlyweightCollection< ITestFlyweight, string> Instantiate() { return new FlyweightCollection< ITestFlyweight, string>( new DelegateTransformer< string, ITestFlyweight>( FlyweightBuilder.Transformation)); } } FlyweightBuilder has two static methods: Instantiate and Transformation. The method Instantiate instantiates the FlyweightCollection class, where the Generic parameter is defined to be ITestFlyweight. This means that this Flyweight pattern implementation creates objects of type ITestFlyweight. The method Transformation instantiates either TestFlyweightA or TestFlyweightB depending on the value of parameter desc. If desc doesn t resolve to one of the two values, an exception is thrown.

The last step in this demonstration of the Flyweight pattern is to have FlyweightBuilder instantiate some types based on a descriptor. Following is the related NUnit test code: [TestFixture] public class TestFlyweight { [Test] public void TestSimple() { IFlyweightCollection< ITestFlyweight, string> var = FlyweightBuilder.Instantiate(); ITestFlyweight var1 = var.GetItem( "TestFlyweightA"); ITestFlyweight var2 = var.GetItem( "TestFlyweightB");

Assert.AreEqual( "TestFlyweightA", var1.Identifier); Assert.AreEqual( "TestFlyweightB", var2.Identifier); ITestFlyweight var1a = var.GetItem( "TestFlyweightA"); Assert.IsTrue( Object.ReferenceEquals( var1, var1a)); ITestFlyweight var2a = var.GetItem( "TestFlyweightB"); Assert.IsTrue( Object.ReferenceEquals( var2, var2a)); } } An instance of the IFlyweightCollection<> interface is instantiated using the method FlyweightBuilder.Instantiate. Then the method GetItem is called twice and assigned to the variables var1 and var2. The variable var1 references an instance of TestFlyweightA, and the variable var2 references an instance of TestFlyweightB. The subsequent Assert statements verify that the correct instances are instantiated. The variable var1a uses the same descriptor as was used to assign the variable var1. The Flyweight pattern dictates that both var1 and var1a reference the same object instance. The proof is the validation using the method Object.ReferenceEquals of var1 and var1a; Assert.IsTrue then checks to see whether the method returns a true value. The same test is performed for the variables var2 and var2a. Let s consider the ramifications of this implementation: There is no way to test whether the returned instantiated type is immutable. The Flyweight pattern dictates that it s immutable, but there is no way to verify it. A way to ensure that only immutable objects are used is to periodically check the hashcode of such an object and ensure that it isn t modified. It s possible to use class instances that can be altered. However, that means multiple clients will be manipulating the same object instance. This violates the Flyweight pattern and introduces state corruption, as multiple threads might be manipulating the same data. But if the objects do change, use the hashcode to check for changes and perform some additional action not defined by the illustrated implementation. There has to be a way to describe the objects you re interested in. In the example, the description consisted of a text buffer, but you could also use an enumeration or a configuration file entry. I previously mentioned that the descriptor should implement either the Dynamic or Static Extension pattern because that makes the descriptor definition flexible. A flyweight descriptor can only refer to one unique state. It isn t possible, nor should it be attempted, to switch the meaning of a descriptor while a Flyweight implementation is being used. In other words, combining the Flyweight pattern with the State pattern isn t a good idea. A very good way of implementing the transformation functor is to use the Chain of Responsibility pattern. This gets away from the hard-coded if statement block given by the example.