• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Junilu Lacar
  • Rob Spoor
  • Paul Clapham
Saloon Keepers:
  • Tim Holloway
  • Tim Moores
  • Jesse Silverman
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Piet Souris
  • Frits Walraven

Simple Factory Pattern Not Generally Applicable in GoF

 
Saloon Keeper
Posts: 1728
63
Eclipse IDE Postgres Database C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have clarified one point, it seems that Garbage Collection was an inherent feature of Smalltalk going way, way back.

So back in 1994 when the GoF Design Patterns book started an explosion of general interest in the topic, the examples were given for two languages, C++ and Smalltalk.

Material targeting a Smalltalk-only audience, around then, certainly later, and as far as I can tell even earlier, would be presuming a garbage collected environment as a given.

Material targeting a C++ audience would NOT be doing so, even today.

So it seems logically obvious that the GoF book, targeting both audiences together, would focus more on patterns that were generally useful to both groups.

In C++, garbage collection is not (generally) a thing, and any confusion about who is responsible for destroying an object is an invitation to disaster, an accident that can't wait to happen.

Many of the creational patterns help achieve loose coupling between users of an interface and the implementation classes.

This is good everywhere.

In all garbage collected languages, at least for immutable objects, the whole notion of who owns an object is pointless and not something a good developer working in client code should even be thinking about.

So "Get me an object of this type, maybe you are creating a new one or maybe not, I couldn't care less." is a recipe for disaster in C++ and quite often the smart way to do things in Smalltalk/Java/C#/Python etc. etc.

I think this is the actual reason that what seems to be generally retconned as the "Simple Factory Pattern" is ubiquitous in Java and, if I am not mistaken, basically ignored in the original GoF presentations.

It could have been presented as a "Smalltalk-only" example back then but from what I gather from material presented by Great Fans of that text, was not.

So the simplest kind of creational pattern in Java "I want one of these, yes, exactly this thing, it is your problem whether you are creating one at this time or just giving me one you already have around, I don't care" is now called a Simple Factory Pattern, if I am not confused.

Even today, this would just be a disaster in C++, and really isn't applicable there.

I am nearly certain there are other C++-isms, and in fact, things specific to 1994-vintage C++ that show thru in the GoF book, but this one is pretty noticeable to me.

I think it is the cause of some confusion in recent discussions, and I am certainly keeping it in mind.
 
Saloon Keeper
Posts: 13477
304
  • Likes 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's not exactly true that in garbage collected languages you don't have to worry about who "owns" an object. There are still objects that must explicitly be disposed when we're done using them. This is why Java has the AutoCloseable interface.

I STRONGLY recommend that you separate your provider interfaces/methods in two categories, and clearly name them accordingly:

  • Factories create objects but are not responsible for disposing the objects they create.
  • Managers may or may not create the objects they provide, but are responsible for disposing them.

  • Methods that create an object and don't care about their lifecycle should have a name that starts with "create" and usually be in a type that has a name that ends with "Factory".

    Methods that return an object whose lifecycle is managed should have a name that starts with something like "get" or "provide". The type name should usually end with something like "Manager" or "Provider".
     
    Jesse Silverman
    Saloon Keeper
    Posts: 1728
    63
    Eclipse IDE Postgres Database C++ Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Stephan:

    I can really get behind that idea, because it makes a clear distinction between things that could easily be confused, with attendant harms if they are.

    To what extent are people already following this inside of and outside of the JDK classes?

     
    Stephan van Hulst
    Saloon Keeper
    Posts: 13477
    304
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I'm not aware of any widely known convention.

    The proposal I gave in my previous post is something I adhere strictly to myself, and I recommend others do as well. However, the most important maxim remains: Read the frogging manual to see who's responsible for the lifecycle of an object.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic