Drawback of using Abstract factory and which pattern address it

Question

I have faced following question in interview for which I could not find any solution on Google or stack overflow. I don't know is it really a valid question(as I wasn't given any context. In which context he was talking about)??

I was asked to tell what is the well know problem with Abstract Factory pattern and which patterns address that issue.

So could anybody help in me figuring out what exactly is that issue( Secret)

What are disadvantages of Abstract factory design pattern?

I had been through this link but couldn't figure out which other pattern address drawbacks of Abstract Factory.

I think answer can be found on http://stackoverflow.com/questions/19508928/what-are-disadvantages-of-abstract-factory-design-pattern — vaibhav sharma, Sep 05 '16 at 07:15

score 2 · Answer 1 · answered Sep 05 '16 at 07:41

2

Quoting from "Design Patterns" by GoF (kind of programmer bible): "Supporting new kinds of products is difficult. Extending abstract factories to produce new kinds of Products isn't easy. That's because the AbstractFactory interface fixes the set of products that can be created. Supporting new kinds of products requires extending the factory interface, which involves changing the AbstractFactory class and all of its subclasses.

answered Sep 05 '16 at 07:41

o_weisman

804
7
19

1

jlvaquero has already answered your question regarding how to extend the factories (see also here: http://www.oodesign.com/abstract-factory-pattern.html) . However, the question from the interview asked which patterns address that issue, which can also mean what alternatives there are to the AbstractFactory pattern that don't suffer from the same problem. If that is the case, I agree with jlvaquero once again that without context this is not a valid question. – o_weisman Sep 20 '16 at 06:50

score 1 · Answer 2 · answered Sep 05 '16 at 17:30

Have a look at sourcemaking article on Abstract Factory.

Sometimes creational patterns are competitors: there are cases when either Prototype or Abstract Factory could be used profitably. At other times they are complementary.

Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed.

For construction of a complex object, Builder is the right choice, which provides more flexibility. May be your interviewer is looking for this kind of answer.

I agree; but the problem with the OP seems that was asked about something extracted from a book that is somewhat opinion-based or with context that was lost when translate to a interview question or the question was a dirty trick... — jlvaquero, Sep 06 '16 at 06:08

score 1 · Answer 3 · answered Sep 06 '16 at 05:53

As @o_weisman says; the main drawback of AF is extensibility but if there is a technique to cover that issue, in a design patter way (general reusable solution to a commonly occurring problem), it would be part of AF by default. So I think that this question without context is not a valid question.

One technique to avoid interface changing and thus break the client is using just one Create method for the creation of all elements. But I doubt this is a pattern with a official name.

i.e. on C#:

namespace ConsoleApplication1
{
  public enum Appearance
  {
    Win,
    OSX
  }
  interface IButton
  {
    void Paint();
  }

  interface ITextBox
  {
    void Paint();
  }

  interface IGUIFactory
  {
    TElement CreateGUIElement<TElement>() where TElement : class;
  }

   class GUIFactory
  {
    public static  IGUIFactory Create(Appearance lookAndFeel) {

      if (lookAndFeel == Appearance.Win) { return new WinFactory(); }
      if (lookAndFeel == Appearance.OSX) { return new OSXFactory(); }
      throw new NotImplementedException();
    }
  }

  abstract class AGUIFactory : IGUIFactory
  {
    public TElement CreateGUIElement<TElement>() where TElement : class
    {
      if (typeof(IButton) == typeof(TElement)) { return CreateButton() as TElement; }
      if (typeof(ITextBox) == typeof(TElement)) { return CreateTextBox() as TElement; }
      throw new NotImplementedException();
    }

    protected abstract IButton CreateButton();
    protected abstract ITextBox CreateTextBox();
  }


  class WinFactory : AGUIFactory
  {
    protected override IButton CreateButton()
    {
      return new WinButton();
    }

    protected override ITextBox CreateTextBox()
    {
      return new WinTextBox();
    }
  }

  class OSXFactory : AGUIFactory
  {
    protected override IButton CreateButton()
    {
      return new OSXButton();
    }

    protected override ITextBox CreateTextBox()
    {
      return new OSXTextBox();
    }
  }

  class WinButton : IButton
  {
    public void Paint()
    {
      Console.WriteLine("Windown button paint");
    }
  }

  class OSXButton : IButton
  {
    public void Paint()
    {
      Console.WriteLine("OSX button paint");
    }
  }

  class WinTextBox : ITextBox
  {
    public void Paint()
    {
      Console.WriteLine("Windown TextBox paint");
    }
  }

  class OSXTextBox : ITextBox
  {
    public void Paint()
    {
      Console.WriteLine("OSX TextBox paint");
    }
  }


  class Program
  {
    static void Main()
    {
      IGUIFactory factory;
      IButton btn;
      ITextBox txb;

      factory = GUIFactory.Create(Appearance.Win); //UserSettings.LookAndFeel
      btn = factory.CreateGUIElement<IButton>();
      txb = factory.CreateGUIElement<ITextBox>();
      btn.Paint();
      txb.Paint();

      factory = GUIFactory.Create(Appearance.OSX);
      btn = factory.CreateGUIElement<IButton>();
      txb = factory.CreateGUIElement<ITextBox>();
      btn.Paint();
      txb.Paint();

      Console.ReadLine();
    }
  }

}

Drawback of using Abstract factory and which pattern address it

3 Answers3