How shall I understand the motivation of abstract factory?

Question

From Design Pattern by GoF

ABSTRACT FACTORY

Intent

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Motivation

Consider a user interface toolkit that supports multiple look-and-feel standards, such as Motif and Presentation Manager. Different look-and-feels define different appearances and behaviors for user interface "widgets" like scroll bars, windows, and buttons. To be portable across look-and-feel standards, an application should not hard-code its widgets for a particular look and feel. Instantiating look-and-feel-specific classes of widgets throughout the application makes it hard to change the look and feel later.

We can solve this problem by defining an abstract WidgetFactory class that declares an interface for creating each basic kind of widget. There's also an abstract class for each kind of widget, and concrete subclasses implement widgets for specific look-and-feel standards. WidgetFactory's interface has an operation that returns a new widget object for each abstract widget class. Clients call these operations to obtain widget instances, but clients aren't aware of the concrete classes they're using. Thus clients stay independent of the prevailing look and feel.

I was wondering what do the following mean:

To be portable across look-and-feel standards, an application should not hard-code its widgets for a particular look and feel.

and

Instantiating look-and-feel-specific classes of widgets throughout the application makes it hard to change the look and feel later.

In particular, without using an abstract factory class, what does the code look like and why is it bad? Thanks.

Answer 1

When something in the code asks for a widget (say Window), not to hardcode means you should not do this:

var window = new DesktopWindow() 

Presumably you create windows in lots of places, so you'll have say, 100 of those window creations. If you did the above, you hardcoded your app to have desktop windows everywhere. Then, if you want to have a mobile version (or some other look) you will have to modify all 100 places to do something like this:

if(environment.IsMobile){
  window = new MobileWindow();
} else {
  window = new DesktopWindow();
}

The more complicated the logic of window creation gets, the harder and bigger the above code could become. You will end up with lots of duplicated code that does the same thing, making it hard to maintain. That's what makes it hard to change look and feel later part means.

With abstract factory your code don't care about what window it gets:

IWindow window = windowFactory.Create();

and the factory actually knows what window to return based on the context. The caller just uses the common interface IWindow to achieve its goals. Factory simplifies the code by keeping the creation logic in one place and makes addition of new Window types (looks and feels) easier.