Tag Archives: IT Univeristy

Bak 2 Basiks – Design Patterns – The Dispose Pattern

Continuing on with the Design Patterns theme – see my last post in this series here – this post is a favorite of mine, mainly because it is is specific to .NET and also because it causes me mental block (for some reason), so what better place to put it for future reference than my blog.  

To understand the workings of this pattern it is important to know how the Garbage Collection Process works in .NET, and since it is an involved subject I shall not clutter this post with these details. 

Essentially this pattern cleans up both managed and unmanaged resources when users of this class call Dispose on object instances.  If the user neglects to call Dispose and the Garbage Collector kicks in, then the Finalizer does the clean up.  Of course, the special thing about finalizers is that they cannot reference managed objects.  This is because the GC may have already freed up the memory of these objects by the time the finalizer executes, hence the need for a disposing toggle and Dispose(boolean) method.

The comments explain all, if you have resource intensive objects in your .NET code be sure to implement this pattern.

public class Dummy : IDisposable
    {
        #region Fields

        private bool _disposed = false;

        #endregion Fields

        #region Destruction

        /// <summary>
        /// Cleanup.
        /// </summary>
        public void Dispose()
        {
            Dispose(true);
            // Take yourself off of the finalization queue
            // to prevent finalization code for this object
            // from executing a second time.
            GC.SuppressFinalize(this);
        }

        /// <summary>
        /// This Finalize method will run only if the
        /// Dispose method does not get called.
        /// </summary>
        public ~Dummy()
        {
            // Do not re-create Dispose clean-up code here.
            // Calling Dispose(false) is optimal in terms of
            // readability and maintainability.
            Dispose(false);
        }

        /// <summary>
        /// Dispose(disposing As Boolean) executes in two distinct scenarios.
        /// If disposing is true, the method has been called directly
        /// or indirectly by a user's code. Managed and unmanaged resources
        /// can be disposed.
        /// If disposing equals false, the method has been called by the runtime
        /// from inside the finalizer and you should not reference other
        /// objects. Only unmanaged resources can be disposed.
        /// </summary>
        /// <param name="disposing">If true then user called dispose, otherwise finalizer called dispose.</param>
        private void Dispose(bool disposing)
        {
            // Check to see if Dispose has already been called.
            if (!_disposed)
            {
                // If disposing equals true, dispose all managed and unmanaged resources.
                if (disposing)
                {
                    // Dispose managed resources.
                }
                // Release unmanaged resources. If disposing is false,
                // only the following code is executed.
                // Note that this is not thread safe.
                // Another thread could start disposing the object
                // after the managed resources are disposed,
                // but before the disposed flag is set to true.
                // If thread safety is necessary, it must be
                // implemented by the client.

            }
            _disposed = true;
        }


        #endregion Destruction
    }

Bak 2 Basiks – Design Patterns – The Strategy Pattern

Design patterns are an ever growing collection of tried and tested best practices for implementing software code.  No matter if your language of choice is C#, Java, C++, or Visual Basic, design patterns present blue prints for development of common object oriented principles. 

Most developers have heard of design patterns, some have used them in different development scenarios, some theorize about them, few people use them continuously in their day-to-day development.  Why?

Even though design patterns exist to make the life of a software developer/programmer easier, they present a learning curve for those not practiced in this area.  The problem with patterns is that there exist so many of them.  Speak to a any talented software developer and ask him/her about design patterns and they’ll probably quote the “Singleton,” “Model View Controller,” “Command,” or “Observer” patterns because these are most common, but many more patterns exist.  Microsoft has reams of online documentation dedicated to patterns, and the Java SDK is built atop of a series of the best used patterns.  So it is no surprise that software developers not practiced in the area shy away from design patterns and stick to traditional ad-hoc methods of software architecture and implementation. 

So, this series of posts is aimed at describing the most common patterns that any well designed software creation is not without.  This first post in the series descries the “Strategy Pattern”…

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable.

In English – this pattern describes a way to abstract out most commonly changing code from code that never changes and encapsulate this commonly changing code so that it can be used or interchanged with other similar code to provide behavior like functionality.

An example:

Let’s assume we have an application that wants to model birds. A base class exists that defines the common attributes of all birds:

class Bird
{
  fly()
}

The fly method provides the method for making our bird fly..but not all birds fly, so our Ostridge throws a NoFly exception.

So, now we have a base bird class, an Ostridge class, and we can implement many more derived bird type classes.  What happens when we want to add a new behavior to our birds, such as “canSwim()”?  This would involve adding an abstract (or virtual) method to the base class and then implementing the same method in all derived classes, but what if we had lots of bird classifications?

Enter the strategy pattern..

Abstract out the code that changes, which in this case is anything behavior related to birds…

interface BirdBehavior
{
  fly()
  canSwim()
}

Implement a series of common behavior types common to groups of birds…

class NoSwimorFly : BirdBehavor { … }
class FlyNoSwim : BirdBehavior { … }
class FlyAndSwim : BirdBehavior { … }

Now assign a bird behavior to bird instance classes…

class Bird
{
    Display(Behavior b)
    {
      b.fly();
      b.canSwim();
    }
}

So, now when a behavior of a bird changes we only need to change the few classification groups and not the large list of birds in our avery application.