mardi 13 août 2019

Design pattern flexibility issue Factory Method

I've been having a recent discussion with a colleague regarding the Factory Method design pattern. One basic approach is that the static method (from the factory class for example )should hide the complex creation logic of the created class:

class IObject {
    //Interface
};

class A :public IObject {

};


class Factory {
    static IObject * create(int type) {
        //All logic goes here
    }
};

The issue is that in our case the factory class will always only return an explicit object of type A. My honest opinion was the the int argument of the static factory method is useless and ads unnecessary complexity.

Also returning an Interface pointer of type IObject is also forced in my opinion. There is no need to return a pointer of base class if there is and always will be only ONE implementation. I think things can be simplified :

class A {
};


class Factory {
    static A createA() {
        //All logic goes here
    }
};

  • My college is arguing that design patterns need to be applied literally and that maybe in the future things will change thus using he's version will simplify things down the road(because the code is more flexibly).
  • I'm adept more to the KISS principal and honesty making code flexible for a feature that might not even exist might invite problems down the road.

As far as what GOF has to say: "The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context. "

The answer seems to indicate that design patterns are more a description on how to solve some things and not a prescription.

So what do you guys think (for this particular case)?

Aucun commentaire:

Enregistrer un commentaire