Understanding the factory method pattern

折月煮酒 提交于 2019-12-22 08:38:58

问题


I'm reading about the Factory Method pattern.

I can understand when there is a single factory class, i.e. StoreFactory#getStore(), that returns a Store implementation based on some runtime or other state.

But, from reading (e.g. this link), there seems to be a general pattern of people creating an abstract factory class, to which other factory classes extend:

 public abstract class AbstractFactory {
     public abstract Store getStore(int store);
 }

 public class StoreFactoryA extends AbstractFactory {
     public Store getStore(int Store) {
         if(Store == 1) { return new MyStoreImplA(); }
         if(Store == 2) { return new MyStoreImplB(); }
     }
 }

 public class StoreFactoryB extends AbstractFactory {
     public Store getStore(int Store) {
         if(Store == 1) { return new MyStoreImplC(); }
         if(Store == 2) { return new MyStoreImplD(); }
     }
 }

 public class Runner {
    public static void main(String[] args) {
        AbstractFactory storeFactory = new StoreFactoryA();
        Store myStore = storeFactory.getStore(1);
    }
 }

My example is contrived, but models that of the aforementioned link.

This implementation seems kind of chicken-egg to me. Use the Factory Method pattern to eliminate the need for the client code to specify a class type, yet now the client code needs to selectively choose the correct factory to use, i.e. StoreFactoryA, StoreFactoryB?

What is the reasoning behind using the abstract class here?


回答1:


The link you are reading unfortunately does not give a realistic example of the pattern. In fact, as per the original GoF Design Patterns, this pattern is called Abstract Factory (Factory method is a different pattern).

Abstract Factory pattern is used when you have factories that can create a family of objects. e.g. You can have and AbstractGUIFactory which can have methods createButton(), createWindow(), createTitleBar etc. And then, you would have concrete factories like WindowsGUIFactory, MacGUIFactory, MotifGUIFactory etc, each of which will produce Button, Window, TitleBar objects in their own way.

The factory will be set to one implementation at some point in the application (probably using configuration) and then that factory will be used wherever the objects need to be created.

If you are learning Design Patterns, the best advice is to start with the classic GoF book.




回答2:


The pattern gets interesting especially when it comes to testing. Now you can inject an AbstractFactory into a class and choose different types for different environments or tests without the need to change the classes (if the factory creates types that share common interfaces).

The using classes don't have to depend on the concrete implementation of a factory and don't have to depend on the real implementations of the created types.




回答3:


When using Factory method, the method is still in the object, and you need to instantiate the correct object to access the method. The only abstraction you achieve, is because of the Abstract class.

The Factory Method pattern is designed in this way. Perhaps, you were expecting it to be something like the Abstract Factory pattern, which has a better abstraction than the Factory Method.

http://c2.com/cgi/wiki?AbstractFactoryVsFactoryMethod




回答4:


You gain extensibility and decoupling through inversion of control, while still allowing the object a margin of control over the actual process and timing.



来源:https://stackoverflow.com/questions/12293427/understanding-the-factory-method-pattern

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!