Factory методы используются обычно в случае необходимости конструирования объектов, класс которых заранее неизвестен.

Например : Вы решили реализовать GUI с поддержкой скинов.
В базовом скине за рендеринг кнопки отвечает класс DefaultButton.
Необходимо сделат поддержку стилей как MacOS X (Aqua).
В принципе можно переписывать реализацию класса DefaultButton, но в силу разных обстоятельств это решение не является оптимальным.
Логично было бы кнопку в стиле Aqua сделать в виде отдельного класса
AquaButton.
здесь возникает 2 проблемы:
1) Везде в коде используется DefaultButton
2) конструктор AquaButton может иметь более другой список параметров, чем
DefaultButton.

Решение в такой ситуации применяется такое :

1) определяется общий предок/интерфейс для взаимодействия с кнопками
AbstractButton.

2) определяется общий предок/интерфейс для классов , которые будут
конструировать кнопки. Например IGUIFactory. В нем реализуется метод
public AbstractButton BuildButton(.....)

3) Создаем реализации кнопок для различных стилей.

4) Создаем реализации IGUIFactory, котоые умеют конструировать кнопки для
различных скинов[Default,Aqua,etc].

5) конструкции
DefaultButton Btn = new DefaultButton(....);
.......
Btn.DoSomething();
заменяются на последовательность действий :
........
IGUIFactory theCurrentButtonFactory = GetButtonFactoryFromSomewere();
........
AbstractButton ABtn = theCurrentButtonFactory.BuildButton();
.....
ABtn.DoSomething();

Недостатки такого подхода :
Необходима серьезная подготовительная работа.
Достоинства:
1) Для того чтобы изменить дизайн всех кнопок достаточно
ТОЛЬКО поменять реализацию GetButtonFactoryFromSomewere()
либо сделать так , чтобы GetButtonFactoryFromSomewere() выбирал
конкретную фабрику на основе настроек. Так или иначе , изменения надо
вносить в 1 [один] файл , а не делать рефакторинг кучи файлов.

2) Конструктивно исключена возможность ошибки вида[ во всех файлах
DefaultButton заменили на AquaButton , а в файле xxxx.java забыли]