Фабричный метод - должен ли класс приложения быть абстрактным?

Книга Эрика Гаммы о дизайне GOF гласит:

введите описание изображения здесь

Принимая во внимание, что приложение word может создавать несколько документов самостоятельно, как показано ниже:

введите описание изображения здесь

Похоже, что одно приложение может создать несколько документов.
Тогда в каком случае мне потребуется сделать класс Application абстрактным, а затем наследовать его?

2 ответа

Решение

Класс приложения, являющийся абстрактным, не является сущностью фабричного паттерна, но нам нужно увидеть его цель. То же самое намерение выполняется абстрактным классом Plugin (в приведенном ниже примере реализации).

Любой класс, откладывающий создание объекта до его подкласса для объекта, с которым он должен работать, можно рассматривать как пример шаблона Factory.

Фабричный шаблон, как описано в GOF, представляет пример возможной реализации приложения документа для понимания, но не специфичного для конкретного приложения Word, но все же мы можем иметь возможное ниже factory method основанный дизайн

Для текущего приложения Word возможный дизайн может быть похож на плагин, где у нас может быть несколько плагинов, и каждый из них может быть добавлен в приложение. Создание сущности (в данном случае Document) выполняется каждым плагином.

Если необходим новый тип документа, тогда можно внедрить плагин и добавить его в приложение.

Возможная структура кода может быть как ниже.

Class Application{
    List<Plugin> plugins ;
    public void addPlugin(Plugin newPlugin){
       plugins.add(newPlugin);
    }
    //more code as per req and features
}

 public abstract class Plugin{
    public abstract Document createNewDocument();
    public void openNewDocument(){
         Document doc = createNewDocument();
         doc.open();// assuming open is a method in Document interface.
           //more code as per req and features
    }
 }

public class PNGPlugin extends Plugin{
     public Document createNewDocument(){
          return new PNGDocument();// Document being the interface for various documents.
     }
       //more code as per req and features
}  

Пункты меню в текущем подходе будут зависеть от списка плагинов.

Распространенным случаем может быть то, что абстрактные классы Application и Document предоставляются используемой платформой (что-то вроде Swing или UIKit или Gnome), и ваш собственный код будет реализовывать их как MyDocument и MyApplication.

Другие вопросы по тегам