What is this Design Pattern?

Question

I read the Wikipedia articles on FactoryMethod and AbstractFactory but the following code doesn't seem to fit anywhere. Can someone explain to me what the following pattern is or if it is an anti-pattern?

interace PaymentGateway{
  void makePayment();
}

class PaypalPaymentGateway implements PaymentGateway
{
  public void makePayment()
  {
    //some implementation
  }
}


class AuthorizeNetPaymentGateway implements PaymentGateway
{
  public void makePayment()
  {
    //some implementation
  }
}

class PaymentGatewayFactory{
  PaymentGateway createPaymentGateway(int gatewayId)
  {
    if(gatewayId == 1)
      return PaypalPaymentGateway();
    else if(gatewayId == 2)
      return AuthorizeNetPaymentGateway();
  }
}

Let's say the user selects the payment method using a radio button on an html page and the gatewayId is derived from the radio button value.

I have seen code like this and thought it was the AbstractFactory pattern but after reading the Wikipedia article, I'm having doubts.

@Juvanis it's not a strategy pattern , the strategy pattern give the you the possibility to change the behavior of your instance on the fly by passing to one of it's method an argument that will be used for dowing the new strategy . — Mifmif, Jun 04 '14 at 08:38

score 2 · Answer 1 · answered Jun 04 '14 at 08:38

the gateway class implements a strategy pattern with selection delegated to what I'd call a parameterized factory.

If you want to reduce it to one of the GOF patterns I'd say it is more like a builder pattern, condensed into a shorthand call instead of setting the strategy and calling build() afterward.

If you want to extend to Fowler patterns, you can compare it to a Registry

score 1 · Answer 2 · answered Jun 04 '14 at 18:22

1

This is not the factory pattern, abstract factory pattern or the builder pattern.There are specific intents of them and non of them matches with the code.

But as some have suggested, interface PaymentGateway and concrete classes implement the strategy pattern. The intent of the strategy pattern matches perfectly: "Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."

Strategy pattern need not necessarily possess on-the-fly behavior change. It depends on the client code (the code that uses the strategy pattern abstraction).

PaymentGatewayFacotry doesn't match with any GoF pattern. It doesn't match with the intent of the factory pattern, abstract factory pattern or the builder pattern. As Lorenzo has suggested, may be you can call it a parameterized factory or a parameterized selector. It is a badly coded class though. It violates the open-close principle.

answered Jun 04 '14 at 18:22

I did not understand why the PaymentGatewayFactory is badly coded. Can you please explain? – Can't Tell Jun 05 '14 at 03:43
Because if you add another PaymentGateway to the system, you need to modify existing PaymentGatewayFactory code. It never ends, right? However, if you are happy with such trouble, you can stop your design effort. If you want that issue to be resolved, you will look at modifying PaymentGatewayFactory. Do you want to live with a Factory that can manufacture only two types of objects? Or do you want a Factory that can manufacture many types of objects of a certain type (PaymentGateway)? – Jun 05 '14 at 06:22
Thanks for the explanation. How would you suggest to make the class conform to open-closed principle? For the factory to instantiate PaymentGateways without knowing the type beforehand, I'm thinking that it would have to get some other object(s) to construct the PaymentGateways for it. And that other object would be of an interface/abstract type? – Can't Tell Jun 05 '14 at 06:37
Read this: [The end of dependency injection - who creates the dependencies?](http://www.deadschool.com/article/end-dependency-injection-who-creates-dependencies) – Jun 05 '14 at 12:57

score 1 · Answer 3 · edited Jun 20 '20 at 09:12

In Craig Larman's book "Applying UML and Patterns" (Section 26.4) he refers to this as the "Simple Factory" or "Concrete Factory" and says it's not a GoF pattern, but is extremely widespread.

"Head First Design Patterns" also devotes space to this pattern:

The Simple Factory isn’t actually a Design Pattern; it’s more of a programming idiom. But it is commonly used, so we’ll give it a Head First Pattern Honorable Mention. Some developers do mistake this idiom for the “Factory Pattern,” so the next time there is an awkward silence between you and another developer, you’ve got a nice topic to break the ice.

Freeman, Eric; Robson, Elisabeth; Bates, Bert; Sierra, Kathy (2004-10-25). Head First Design Patterns (Kindle Locations 1920-1923). O'Reilly Media. Kindle Edition.

[Edit] I like this blog entry explaining the difference between Simple Factory, Factory Method and Abstract Factory.

What is this Design Pattern?

3 Answers3

Linked