How to implement the factory method pattern in C correctly

Question

There s this one thing in C   which has been making me feel uncomfortable for quite a long time  because I honestly don t know how to do it  even though it sounds simple   How do I implement Factory Method in C   correctly   Goal  to make it possible to allow the client to instantiate some object using factory methods instead of the object s constructors  without unacceptable consequences and a performance hit    By  Factory method pattern   I mean both static factory methods inside an object or methods defined in another class  or global functions  Just generally  the concept of redirecting the normal way of instantiation of class X to anywhere else than the constructor    Let me skim through some possible answers which I have thought of     0  Don t make factories  make constructors   This sounds nice  and indeed often the best solution   but is not a general remedy  First of all  there are cases when object construction is a task complex enough to justify its extraction to another class  But even putting that fact aside  even for simple objects using just constructors often won t do   The simplest example I know is a 2-D Vector class  So simple  yet tricky  I want to be able to construct it both from both Cartesian and polar coordinates  Obviously  I cannot do   struct Vec2       Vec2 float x  float y       Vec2 float angle  float magnitude      not a valid overload                  My natural way of thinking is then   struct Vec2       static Vec2 fromLinear float x  float y       static Vec2 fromPolar float angle  float magnitude                   Which  instead of constructors  leads me to usage of static factory methods    which essentially means that I m implementing the factory pattern  in some way   the class becomes its own factory    This looks nice  and would suit this particular case   but fails in some cases  which I m going to describe in point 2  Do read on   another case  trying to overload by two opaque typedefs of some API  such as GUIDs of unrelated domains  or a GUID and a bitfield   types semantically totally different  so - in theory - valid overloads  but which actually turn out to be the same thing - like unsigned ints or void pointers     1  The Java Way  Java has it simple  as we only have dynamic-allocated objects  Making a factory is as trivial as   class FooFactory       public Foo createFooInSomeWay                can be a static method as well              if we don t need the factory to provide its own object semantics             and just serve as a group of methods         return new Foo some  args             In C    this translates to   class FooFactory   public      Foo  createFooInSomeWay             return new Foo some  args              Cool  Often  indeed  But then- this forces the user to only use dynamic allocation  Static allocation is what makes C   complex  but is also what often makes it powerful  Also  I believe that there exist some targets  keyword  embedded  which don t allow for dynamic allocation  And that doesn t imply that the users of those platforms like to write clean OOP   Anyway  philosophy aside  In the general case  I don t want to force the users of the factory to be restrained to dynamic allocation     2  Return-by-value  OK  so we know that 1  is cool when we want dynamic allocation  Why won t we add static allocation on top of that   class FooFactory   public      Foo  createFooInSomeWay             return new Foo some  args             Foo createFooInSomeWay             return Foo some  args              What  We can t overload by the return type  Oh  of course we can t  So let s change the method names to reflect that  And yes  I ve written the invalid code example above just to stress how much I dislike the need to change the method name  for example because we cannot implement a language-agnostic factory design properly now  since we have to change names - and every user of this code will need to remember that difference of the implementation from the specification   class FooFactory   public      Foo  createDynamicFooInSomeWay             return new Foo some  args             Foo createFooObjectInSomeWay             return Foo some  args              OK    there we have it  It s ugly  as we need to change the method name  It s imperfect  since we need to write the same code twice  But once done  it works  Right   Well  usually  But sometimes it does not  When creating Foo  we actually depend on the compiler to do the return value optimisation for us  because the C   standard is benevolent enough for the compiler vendors not to specify when will the object created in-place and when will it be copied when returning a temporary object by value in C    So if Foo is expensive to copy  this approach is risky   And what if Foo is not copiable at all  Well  doh   Note that in C  17 with guaranteed copy elision  not-being-copiable is no problem anymore for the code above   Conclusion  Making a factory by returning an object is indeed a solution for some cases  such as the 2-D vector previously mentioned   but still not a general replacement for constructors     3  Two-phase construction  Another thing that someone would probably come up with is separating the issue of object allocation and its initialisation  This usually results in code like this   class Foo   public      Foo                empty or almost empty                      class FooFactory   public      void createFooInSomeWay Foo amp  foo  some  args       void clientCode         Foo staticFoo      auto ptr lt Foo gt  dynamicFoo   new Foo        FooFactory factory      factory createFooInSomeWay  amp staticFoo       factory createFooInSomeWay  amp dynamicFoo get                    One may think it works like a charm  The only price we pay for in our code     Since I ve written all of this and left this as the last  I must dislike it too     Why   First of all    I sincerely dislike the concept of two-phase construction and I feel guilty when I use it  If I design my objects with the assertion that  if it exists  it is in valid state   I feel that my code is safer and less error-prone  I like it that way   Having to drop that convention AND changing the design of my object just for the purpose of making factory of it is   well   unwieldy   I know that the above won t convince many people  so let s me give some more solid arguments  Using two-phase construction  you cannot    initialise const or reference member variables  pass arguments to base class constructors and member object constructors    And probably there could be some more drawbacks which I can t think of right now  and I don t even feel particularly obliged to since the above bullet points convince me already   So  not even close to a good general solution for implementing a factory     Conclusions   We want to have a way of object instantiation which would     allow for uniform instantiation regardless of allocation  give different  meaningful names to construction methods  thus not relying on by-argument overloading   not introduce a significant performance hit and  preferably  a significant code bloat hit  especially at client side  be general  as in  possible to be introduced for any class    I believe I have proven that the ways I have mentioned don t fulfil those requirements   Any hints  Please provide me with a solution  I don t want to think that this language won t allow me to properly implement such a trivial concept

User · Answer

I don t try to answer all of my questions  as I believe it is too broad  Just a couple of notes      there are cases when object construction is a task complex enough to justify its extraction to another class    That class is in fact a Builder  rather than a Factory      In the general case  I don t want to force the users of the factory to be restrained to dynamic allocation    Then you could have your factory encapsulate it in a smart pointer  I believe this way you can have your cake and eat it too   This also eliminates the issues related to return-by-value      Conclusion  Making a factory by returning an object is indeed a solution for some cases  such as the 2-D vector previously mentioned   but still not a general replacement for constructors    Indeed  All design patterns have their  language specific  constraints and drawbacks  It is recommended to use them only when they help you solve your problem  not for their own sake   If you are after the  perfect  factory implementation  well  good luck

User · Answer

Have you thought about not using a factory at all  and instead making nice use of the type system  I can think of two different approaches which do this sort of thing   Option 1   struct linear       linear float x  float y    x  x   y  y        float x       float y       struct polar       polar float angle  float magnitude    angle  angle    magnitude  magnitude         float angle       float magnitude        struct Vec2       explicit Vec2 const linear  amp l                    explicit Vec2 const polar  amp p                     Which lets you write things like   Vec2 v linear 1 0  2 0      Option 2   you can use  tags  like the STL does with iterators and such  For example   struct linear coord tag linear coord        declare type and a global struct polar coord tag polar coord      struct Vec2       Vec2 float x  float y  const linear coord tag  amp                     Vec2 float angle  float magnitude  const polar coord tag  amp                      This second approach lets you write code which looks like this   Vec2 v 1 0  2 0  linear coord     which is also nice and expressive while allowing you to have unique prototypes for each constructor

User · Answer

First of all  there are cases when   object construction is a task complex   enough to justify its extraction to   another class    I believe this point is incorrect  The complexity doesn t really matter  The relevance is what does  If an object can be constructed in one step  not like in the builder pattern   the constructor is the right place to do it  If you really need another class to perform the job  then it should be a helper class that is used from the constructor anyway   Vec2 float x  float y   Vec2 float angle  float magnitude      not a valid overload    There is an easy workaround for this   struct Cartesian     inline Cartesian float x  float y   x x   y y       float x  y     struct Polar     inline Polar float angle  float magnitude   angle angle   magnitude magnitude       float angle  magnitude     Vec2 const Cartesian  amp cartesian   Vec2 const Polar  amp polar     The only disadvantage is that it looks a bit verbose   Vec2 v2 Vec2  Cartesian 3 0f  4 0f      But the good thing is that you can immediately see what coordinate type you re using  and at the same time you don t have to worry about copying  If you want copying  and it s expensive  as proven by profiling  of course   you may wish to use something like Qt s shared classes to avoid copying overhead   As for the allocation type  the main reason to use the factory pattern is usually polymorphism  Constructors can t be virtual  and even if they could  it wouldn t make much sense  When using static or stack allocation  you can t create objects in a polymorphic way because the compiler needs to know the exact size  So it works only with pointers and references  And returning a reference from a factory doesn t work too  because while an object technically can be deleted by reference  it could be rather confusing and bug-prone  see Is the practice of returning a C   reference variable  evil  for example  So pointers are the only thing that s left  and that includes smart pointers too  In other words  factories are most useful when used with dynamic allocation  so you can do things like this   class Abstract     public      virtual void do     0      class Factory     public      Abstract  create        Factory f  Abstract  a   f create    a- gt do      In other cases  factories just help to solve minor problems like those with overloads you have mentioned  It would be nice if it was possible to use them in a uniform way  but it doesn t hurt much that it is probably impossible

User · Answer

Factory Pattern  class Point   public    static Point Cartesian double x  double y   private       And if you compiler does not support Return Value Optimization  ditch it  it probably does not contain much optimization at all

User · Answer

Simple Factory Example     Factory returns object and ownership    Caller responsible for deletion   include  lt memory gt  class FactoryReleaseOwnership    public      std  unique ptr lt Foo gt  createFooInSomeWay          return std  unique ptr lt Foo gt  new Foo some  args                 Factory retains object ownership    Thus returning a reference   include  lt boost ptr container ptr vector hpp gt  class FactoryRetainOwnership    boost  ptr vector lt Foo gt   myFoo    public      Foo amp  createFooInSomeWay             Must take care that factory last longer than all references           Could make myFoo static so it last as long as the application        myFoo push back new Foo some  args          return myFoo back

User · Answer

I know this question has been answered 3 years ago  but this may be what your were looking for   Google has released a couple of weeks ago a library allowing easy and flexible dynamic object allocations  Here it is  http   google-opensource blogspot fr 2014 01 introducing-infact-library html

User · Answer

You can read a very good solution in  http   www codeproject com Articles 363338 Factory-Pattern-in-Cplusplus  The best solution is on the  comments and discussions   see the  No need for static Create methods    From this idea  I ve done a factory  Note that I m using Qt  but you can change QMap and QString for std equivalents    ifndef FACTORY H  define FACTORY H   include  lt QMap gt   include  lt QString gt   template  lt typename T gt  class Factory   public      template  lt typename TDerived gt      void registerType QString name                static assert std  is base of lt T  TDerived gt   value   Factory  registerType doesn t accept this type because doesn t derive from base class             createFuncs name     amp createFunc lt TDerived gt              T  create QString name            typename QMap lt QString PCreateFunc gt   const iterator it    createFuncs find name           if  it     createFuncs end                  return it value                        return nullptr         private      template  lt typename TDerived gt      static T  createFunc                 return new TDerived               typedef T    PCreateFunc         QMap lt QString PCreateFunc gt   createFuncs       endif    FACTORY H   Sample usage   Factory lt BaseClass gt  f  f registerType lt Descendant1 gt   Descendant1    f registerType lt Descendant2 gt   Descendant2    Descendant1  d1   static cast lt Descendant1  gt  f create  Descendant1     Descendant2  d2   static cast lt Descendant2  gt  f create  Descendant2     BaseClass  b1   f create  Descendant1    BaseClass  b2   f create  Descendant2

User · Answer

Loki has both a Factory Method and an Abstract Factory  Both are documented  extensively  in Modern C   Design  by Andei Alexandrescu  The factory method is probably closer to what you seem to be after  though it s still a bit different  at least if memory serves  it requires you to register a type before the factory can create objects of that type

User · Answer

This is my c  11 style solution  parameter  base  is for base class of all sub-classes  creators  are std  function objects to create sub-class instances  might be a binding to your sub-class  static member function  create some args    This maybe not perfect but works for me  And it is kinda  general  solution   template  lt class base  class    params gt  class factory   public    factory        factory const factory  amp     delete    factory  amp operator  const factory  amp     delete     auto create const std  string name  params    args        auto key   your hash func name c str    name size         return std  move create key  args              auto create key t key  params    args        std  unique ptr lt base gt  obj creators  key  args           return obj         void register creator const std  string name                          std  function lt base   params     gt   amp  amp creator        auto key   your hash func name c str    name size         creators  key    std  move creator        protected    std  unordered map lt key t  std  function lt base   params     gt  gt  creators        An example on usage   class base   public    base int val    val  val        virtual  base     std  cout  lt  lt   base destroyed n      protected    int val    0      class foo   public base   public    foo int val    base val    std  cout  lt  lt   foo    lt  lt  val  lt  lt     n        static foo  create int val    return new foo val        virtual  foo     std  cout  lt  lt   foo destroyed n         class bar   public base   public    bar int val    base val    std  cout  lt  lt   bar    lt  lt  val  lt  lt    n        static bar  create int val    return new bar val        virtual  bar     std  cout  lt  lt   bar destroyed n         int main       common  factory lt base  int gt  factory     auto foo creator   std  bind  amp foo  create  std  placeholders   1     auto bar creator   std  bind  amp bar  create  std  placeholders   1      factory register creator  foo   foo creator     factory register creator  bar   bar creator            auto foo obj   std  move factory create  foo   80        foo obj reset                 auto bar obj   std  move factory create  bar   90        bar obj reset

User · Answer

extern std  pair lt std  string view  Base       gt  const factories 2    decltype factories  factories      quot blah quot        - gt  Base  return new Blah         quot foo quot        - gt  Base  return new Foo

User · Answer

I mostly agree with the accepted answer  but there is a C  11 option that has not been covered in existing answers    Return factory method results by value  and Provide a cheap move constructor    Example   struct sandwich        Factory methods    static sandwich ham      static sandwich spam         Move constructor    sandwich sandwich  amp  amp         etc       Then you can construct objects on the stack   sandwich mine sandwich  ham       As subobjects of other things   auto lunch   std  make pair sandwich  spam    apple       Or dynamically allocated   auto ptr   std  make shared lt sandwich gt  sandwich  ham       When might I use this   If  on a public constructor  it is not possible to give meaningful initialisers for all class members without some preliminary calculation  then I might convert that constructor to a static method  The static method performs the preliminary calculations  then returns a value result via a private constructor which just does a member-wise initialisation   I say  might  because it depends on which approach gives the clearest code without being unnecessarily inefficient

[c++] How to implement the factory method pattern in C++ correctly

Examples related to c++

Examples related to design-patterns

Examples related to idioms

Examples related to factory-method