Abstract Factory - II Abstract Factory vs Factory

by ipsit 3. August 2009 17:32
The other day we had a discussion related to the abstract factory and let me tell you, flames flew and it was high on melodrama.
Anyways coming back to the main point, the root of whole discussion was,
A: Why should I use the abstract factory, just for a parallel set of classes, what am I getting out of it ?
B: You are abstracting your product, that's why you are creating it. Apart from that, its a you have a mechanism for creating related set of products, which is important here, you see you should not forget that, its for creating a set of related family of products.
C: But say if you are just creating is two set of components, a UI Components for rich mode and the simple mode, could you not do with a static Factory implementation instead of so much of fun fare? And also if you look closely, what you are doing is essentially now binding your classes to the implementation of the Abstract Factories some where, because to get the code running you have to write the Implementation class some where, so would not it be better if we had just a static factory class which gives us what we need.
B: hmmmm...
A: Apart from that so much of code to manage .... That's a good one C:)
C: Thanks! Man
B: Factory Method defines an interface for creating an object, but lets subclasses decide which of those to instantiate. A factory method lets classes defer instantiation to subclasses.By contrast, an Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes.
C: We have a family of related objects but, ... I don't want to take a purists view or go by book view.. I look at convinience and unless you tell me why, I don't see any reason why I should not go for a Factory than a Abstract Factory here.
A: And if you ask me, I guess you are over complicating, is not this kind of an YAGNI.  
B: Well, let me examine the definitions a bit more:
Factory Method defines an interface for creating an object, but lets subclasses decide which of those to instantiate. A factory method lets classes defer instantiation to subclasses.
Which essentially means, in this case the decision is taken by sub class -> Inheritance is in action.
Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes. Now in this case the job of creating the instance of the products are delegated -> Composition in Action.
And as you guys already know Composition allows you to delay the creation of back-end objects until (and unless) they are needed, as well as changing the back-end objects dynamically throughout the lifetime of the front-end object. With inheritance, you get the image of the superclass in your subclass object image as soon as the subclass is created, and it remains part of the subclass object throughout the lifetime of the subclass.
So I would say, if you need it dynamically vary, take the composition root and enjoy the benefits of Abstarct Factory else, Factory should be just fine for you.
C: hmmm..
A: ok
Hope you like the dialogue....:)

Currently rated 4.0 by 1 people

  • Currently 4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Design Pattern | General | MAPI | Refactoring

Abstract Factory - I

by ipsit 3. August 2009 09:26
Intent:

Provide interface for creating families of related or dependent classes without specifying there concrete classes.

Scenario:

I have been wondering about a valid scenario where I would put the Abstract Factory Into play. To be honest it took me some time to really find a valid scenario where I should use it. The catch is "creating families of related or dependent classes", and where would one need this. Where is it being used. We are currently working on development of a framework. Initially it used to have a Telerik controls based UI. And we also used the Ribbon Bar implementation on top of the telerik controls. What this did was made our pages heavy, in the rounds of ~2MB. This made us thinking, not everybody, would be happy to use it this way, so we thought of coming up with a light UI something that limits the page sizes considerabley. In the light UI, we are not using any ribbon controls, rather its a normal menu. Having said that, the solution that you are going to see is just not Abstract Factory only, so I would just omit out the other unrelevant in the context of the post. Apart from the above mentioned scenario, the other place it gets utilizied is ADO.Net. The idea is if you are using a SQL Data Provider then the Connection class should be of SqlConnection noly, like wise the SQLCommand class, the SQLDataAdapter class and so forth. But instead if you are connecting to a MySQL Database, then the connection class would be probably MySqlConnection class and like wise, MySqlCommand class and so forth. If you can notice a pattern, we are talking of creating a family of related products. Lets now look at the Abstract Factory:

              
What the Abstract factory says is,
  • You define Abstract classes for the related products- In our case, we will have AbstractButton, AbstractDropdown for the UI Problem and in case of ADO.Net we have IDBConnection interface and IDBCommand and etc.
  • Then you define a Abstract Factory for creating the different instances of your abstract products - In our case, we would have CreateButton, CreateDropdown etc. I am not aware if, ADO.Net does provide a factory class.
  • Then what we need is implement the Abstract classes and Abstract Factory for creation of the related products and each group of related products being reprsented by a Implementation of the Factory.
What you get out of it ?
  • You abstract the creation process of the components from the code and this allows you to replace it by some other implementation of the Abstract Product. Flexibility and loose coupling is what you gain.
  • Reusablilty of the same code that uses your Abstract Products.
Sample:
using System;


namespace Coderslog.Tryst.DesignPatterns
{
    //interface representing a Button
    public interface IButton
    {
        //Button Properties
    }

    public class SimpleButton : IButton
    {
    }
        
    public class RichButton : IButton
    {
    }

    //interface representing a TextBox
    public interface ITextBox
    {
        //TextBox Properties
    }

    public class SimpleTextBox : ITextBox
    {
    }
    
    public class RichTextBox : ITextBox
    {
    }

    //Abstract Factory interface for Creating UI Components
    public interface IUIComponentFactory
    {
        IButton GetButton();
        ITextBox GetTextBox();
    }

    //Factory Class for Creating Simple UI Components
    public class SimpleUIFactory : IUIComponentFactory
    {

        #region IUIComponentFactory Members

        public IButton GetButton()
        {
            return new SimpleButton();
        }

        public ITextBox GetTextBox()
        {
            return new SimpleTextBox();
        }

        #endregion
    }

    //Factory Class for Creating Rich UI Components
    public class RichUIFactory : IUIComponentFactory
    {
        #region IUIComponentFactory Members

        public IButton GetButton()
        {
            return new RichButton();
        }

        public ITextBox GetTextBox()
        {
            return new RichTextBox();
        }

        #endregion
    }


    ///Usage
    public class UIComponentFactory : IUIComponentFactory
    {

        private IUIComponentFactory _internalFactory;

        public UIComponentFactory()
        {
            _internalFactory = new RichUIFactory();
        }

        public UIComponentFactory(string config)
        {
            if (config == "Simple")
                _internalFactory = new SimpleUIFactory();
            else
                _internalFactory = new RichUIFactory();
        }

        #region IUIComponentFactory Members

        public IButton GetButton()
        {
            return _internalFactory.GetButton();                
        }

        public ITextBox GetTextBox()
        {
            return _internalFactory.GetTextBox();
        }

        #endregion
    }

}

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Design Pattern

SQL Locks - Part 3

by sanket 16. February 2009 18:44

Having outlined an approach, even if its not a approapriate one, we are now intrested in seeing a better solution that is much cleaner than the previous one.

As we re-collect from the previous post our generalized problem was, "There is a addition to behaviour in some scenarios".

We decided to use a Decorator.

What we did was created a interface called IWebPageGenerator, which had a method Generate. Now, the original class was made to  implement from the interface IWebPageGenerator.And all the calls we initiated in the original class was from the Generate Method.

As for the scenario which required a Security check what we did was,

/*           SecurityDecorator                    */

public class SecurityDecorator:IWebPageGenerator{

      public IWebPageGenerator ChildWebPageGenerator {get; private set;}

      public SecurityManager _securityManager;

      public SecurityDecorator(IWebPageGenerator childWebPageGenerator){

             ChildWebPageGenerator = childWebPageGenerator;

             _securityManager = SecurityManager.Instance.Context(Privelege.Metadata.Update);

      }

      public string Generate(){

             _securityManager.Verify();

             return ChildWebPageGenerator.Generate();  

      }

}

/*               Usage                            */

var  webPageGenerator = new SecurityDecorator(webPageGenerator);

/*                                                */

As you can see what this approach brings in is lesser number of code changes. And a more cleaner code base. And the bonus is a better infrastructure of Web Pages Generator which is flexible and extensible.

- Till then Happy Coding :)

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags:

Refactoring | Design Pattern


Inida

About Coderslog

One fine day we thought, we need to be contributing to our community.

So good sense prevailed, and that's how coderslog got started. That's about us.

Calendar

<<  March 2010  >>
MoTuWeThFrSaSu
22232425262728
1234567
891011121314
15161718192021
22232425262728
2930311234

View posts in large calendar

RecentPosts

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2010 CodersLog