Factory method - Does application class need to be abstract?

Question

Erich Gamma's GOF design pattern book says:

Whereas the word application can create several documents on its own as shown below:

It appears that one application can create several documents.
In what kind of case then will I require to make Application class abstract and then derive from it?

Powers

From what I can see from your example; every case will have Application abstract since CreateDocument can't be made general – Derris

@Powers In current case you can have a plugin based design where you can have the document creation in separate plugin class. The Base Plugin class responsible for document creation can have createDocument as abstract. You can refer my answer below, hope it is helpful. – Convector

How do you know that Word uses the Factory Method pattern? – Girgenti

@Powers are there still some unclear points, again we can try to figure out the solution to the unclear points – Convector

Answer 1

Application class being abstract is not the essence of factory pattern, but we need to see the intent behind it. The same intent is being fulfilled by abstract Plugin class ( in below example implementation).

Any class deferring the object creation to its sub class for the object it needs to work with can be seen as an example of Factory pattern.

Factory pattern as described in GOF presents an example of possible implementation of document application for understanding but not specific to specific Word application but still we can have a possible below factory method based design

For current Word application a possible design can be similar to plugin based where we can have multiple plugins and each can be added to the application. The entity(in this case Document) creation is done by the each plugin.

If a new type of document is needed then a plugin can be implemented and added to the application.

A possible structure of the code can be like below.

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
}  

Menu items will in current approach depend upon the list of plugins.

Convector

So, the current word document implemented by you is also an example of factory method? – Powers

yes, Plugin base class is the Factory class in my implementation – Convector

At present there may be n number of possible plugins supported and later more can be implemented. document creation is degegated to each implementation of plugin class – Convector

Plugin base class needs to open the document but wants to defer the document implementation type to the actual implementation of plugin class. In such a case it can do so (open the document) by being dependent upon Interface of document and invkoing the open() method as declared by the document interface. For getting the actual object it defers it to an abstract method createDocument() which is implemented by concrete plugin classes. – Convector

please give me some time to read your answer again. Thanks for your patience. – Powers

Answer 2

The common case would be that the Application and Document abstract classes are provided by the framework that you use (something like Swing or UIKit or Gnome), and your own code would implement them as MyDocument and MyApplication.

Allnight