0

I would like to check if my understanding in using and implementing factory pattern. Say I am designing an Application to play several Games (chess, poker). The games are loaded from one of the following sources: CSV, XML but I want the ability to add new sources (say DB) without recompiling/redeploying the Application.I just want to deploy the factory logic and the new loader

This suggests a factory pattern for the game loader, something like the following which however causes circular dependencies because the concrete loaders returns a List. 

Application.prj has reference to AbstractFactory.prj
-----------------------

    main ()
    List<Game> games = LoadGameFactory.Create(src).Load(src)
    foreach(game in games) game.play();

abstract class Game { .. abstract void Play(); ..}
class Chess : Game  { .. void   Play() ..}
class Poker : Game  { .. void   Play() ..}

Factory.prj has reference to Application.prj
------------------------
class LoadGameFactory { 
    GameLoader Create(string src)
    {
        if(src == csv) return new LoadCSVGames().Load(src)
        else           return new LoadXMLGames().Load(src)      
    }
}
class GameLoader{ List<Game> Load(src) }

class CSVLoader : GameLoader
{
    List<Game> Load(src){ ... logic to create Chess() and Poker() from CSV file}
}

class XMLLoader : GameLoader
{
    List<Game> Load(src)    { ... logic to create Chess() and Poker() from XML file}
}

The solution I found is to create a new project, Application.Model, where I move the Game, Chess, and Poker, ecc That way, Application.prj and Factory.prj will need to reference just Application.Model. And adding DB source requires only factory.prj recompilation and deployment.

Is this the way to go? or is there a way to implement the factory pattern to get the same result. I don't want reflection.

aljj
  • 106
  • 5

1 Answers1

0

It sounds like you want a plugin-based design. I'm assuming this is C#. What you want to do is design a strict set of Interfaces, that define the games, game loader, etc. Then you use Assembly.LoadFrom() to load all the DLLs, and use reflection to get the exported classes that inherit from those interfaces, from those assemblies, and instantiate new objects.

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
  • well, I know that with reflection is possibile to do that, but my queastion is more about how to implement a factory pattern to avoid building the main app. – aljj Jul 22 '12 at 21:08
  • I'm not sure what that means. I think you're mixing up several different things here. The factory pattern pretty much just means that there is no public constructor for a class, and instead, you have to call a static "factory method" to get an instance. Typically, because the factory method does slightly complex things to get you that instance. (For example, it may be actually returning some derived type from what you're expecting.) – Jonathon Reinhart Jul 22 '12 at 22:26
  • ok, I agree with what factory pattern is. However it is a reasonable requirement to structure it such that we can add a new concrete class and the instantion logic to the factory method without casuing a recompilation of the consumer of the factory. Specifically if you have a big consumer that requires hours to compile and hours to deploy. I found a way to get to this, and I am asking if there is a better way (no reflection) – aljj Jul 23 '12 at 20:31