Skip to main content

VBA versus .NET

Lazy Initialization


A fairly straightforward 'fill-in-the-blanks' example of a Lazy Initialization design pattern, except that this uses an enumeration for the type - I hate passing strings, so easy to screw up - as well as a struct for the type that is lazily initialized:

Code

using System;
using System.Collections.Generic;

namespace DesignPatterns
{
    public class LazyFactoryObject
    {
        //internal collection of items
        //IDictionaery makes sure they are unique
        private IDictionary<LazyObjectType, LazyObject> _LazyObjectList = 
            new Dictionary<LazyObjectType, LazyObject>();

        //enum for passing name of type required
        //avoids passing strings and is part of type ahead
        public enum LazyObjectType
        { 
            None,
            Small,
            Big,
            Bigger,
            Huge
        }

        //standard type of object that will be constructed
        public struct LazyObject
        {
            public LazyObjectType Name;
            public IList<int> Result;
        }

        //takes type and create 'expensive' list
        private IList<int> Result(LazyObjectType name)
        {
            IList<int> result = null;

            switch (name)
            { 
                case LazyObjectType.Small:
                    result = CreateSomeExpensiveList(1, 100);
                    break;
                case LazyObjectType.Big:
                    result = CreateSomeExpensiveList(1, 1000);
                    break;
                case LazyObjectType.Bigger:
                    result = CreateSomeExpensiveList(1, 10000);
                    break;
                case LazyObjectType.Huge:
                    result = CreateSomeExpensiveList(1, 100000);
                    break;
                case LazyObjectType.None:
                    result = null;
                    break;
                default:
                    result = null;
                    break;
            }

            return result;
        }

        //not an expensive item to create, but you get the point
        //delays creation fo some expensive object until needed
        private IList<int> CreateSomeExpensiveList(int start, int end)
        {
            IList<int> result = new List<int>();

            for (int counter = 0; counter < (end - start); counter++)
            {
                result.Add(start + counter);
            }

            return result;
        }

        public LazyFactoryObject()
        { 
            //empty constructor
        }

        public LazyObject GetLazyFactoryObject(LazyObjectType name)
        {
            //yes, i know it is illiterate and inaccurate
            LazyObject noGoodSomeBitch;

            //retrieves LazyObjectType from list via out, else creates one and adds it to list
            if (!_LazyObjectList.TryGetValue(name, out noGoodSomeBitch))
            {
                noGoodSomeBitch = new LazyObject();
                noGoodSomeBitch.Name = name;
                noGoodSomeBitch.Result = this.Result(name);

                _LazyObjectList.Add(name, noGoodSomeBitch);
            }

            return noGoodSomeBitch;
        }
    }
}

Comments

Popular posts from this blog

Decorator Pattern

This is an example of the Decorator pattern, in this case a decorator for ObservableCollection.  Working with WPF and ObservableCollection using threads, one will run into the problem whereby the ObservableCollection cannot be updated from outside the owning thread; Delegates and Invoke will not work. A solution is to contain and expand the class, as is done in this example on michIG's Blog . This linked file contains the original code in C#, as well as the same code converted to VB.NET. Salient Characteristic(s) Sets an internal pointer to the decorated object, sending method calls and property actions to the internal object Extends the object by wrapping it and adding some aspect handled by the decorator Code using System; using System.Collections.ObjectModel; using System.Windows.Threading; using System.Collections.Specialized; using System.ComponentModel; namespace DesignPatterns {     /// <summary>       /// This class is an...

James Igoe's Reviews > Thinking Architecturally

Thinking Architecturally by Nathaniel Schutta My rating: 4 of 5 stars An overview of architectural decisions, the politics and persuasion involved, and the needs to balance competing measures and attributes. A fairly easy read, but full of great suggestions, and, for many, reminders of how to handle being a senior developer or architect. View all my reviews

Migrating and Design Planning

I have been toying with the idea of migrating one of my sites to a better host - it was supported by Yahoo and now AAbaco - and implementing some newer technologies. Among products I have used at work or are working with peripherally, I am considering using ASP.NET MVC, Entity Framework, ReSTful API's, NoSQL, and Azure-hosted databases - it is currently a mixture of very low-end PHP, HTML5/CSS3, light Javascript, and MySQL - so I decided to write up an architectural diagram - it looks like any standard architecture, with maybe a few additional elements - to help with the planning: