I have concrete factory classes which implement MyFactory interface. I want to get concrete factory objects based on parameter. How to do this?

One way is to create factory of factories[FoF], and FoF would be parameterized factory.

Is there any more elegant way to do this?

This is purely intellectual exercise, I am not facing any problem in my project.

  • 1
    The MyFactory interface is generic? I can't imagine how you could have multiple factories implement the same interface, considering the point of a factory is to create an object of a concrete type, thus the definitions between the factories would differ.
    – Andy
    Commented Nov 27, 2015 at 12:58
  • 1
    @q126y - so you have a BikeFactory - why do you need multiple BikeFactories?
    – HorusKol
    Commented Nov 27, 2015 at 13:09
  • 3
    @q126y: The BikeFactory would have a method createBike(id) that creates the appropriate Bike based on the passed ID. What would be the use of the FoF? Commented Nov 27, 2015 at 13:13
  • 7
    A factory of factories is called an industry.
    – Mike Nakis
    Commented Nov 27, 2015 at 13:35
  • 2
    @q126y: I don't know how games like GTA work or how important a vehicle type is there. For all I know, they just have a single factory that creates vehicles. Why would I use a separate BikeFactory and CarFactory if in the end I just want to have a vehicle and I don't care in the code if that vehicle is a car or a bike. Commented Nov 27, 2015 at 14:52

3 Answers 3


Indeed, when using the Abstract Factory pattern, somewhere in your program a decision must be made which of the concrete Factory classes will be instantiated. And the method which does this will typically be a Factory method. It will be less confusing if you distinguish clearly between these two terms.


Yes, you would have Factory of Factories. The key point is that this either class or method should be in topmost library/application. Only smallest possible part of the application should know about this FoF. It could very well be a simple method in launcher of the application that is executed before the main loop of the application executes.

If you were tempted to create interface for this FoF, then that would be indication that your creation scheme might use redesign.

Edit : It seems we need to clarify what I mean by Factory (actually Abstract factory, but I don't consider "a Factory" as pattern. Abstract Factory pattern is solution to a situation, where some piece of code needs to create an instance, but the piece of code itself doesn't have enough information to decide which instance to create. That is why the client exposes an abstraction and someone who has information to create that instance realizes that abstraction.

If you want to talk about design, you MUST ALWAYS tell us how is it going to be used and who has what information.

  • Is it okay to use in GTA like game, to generate different vehicles, cars, bikes, motorcycles, etc. ? Do they hard code it? or to spawn random vehicle on next turn, say,getVehicleindustry(randomVehicleIDgenerator), call buildVehicle() on the returned factory?
    – q126y
    Commented Nov 27, 2015 at 14:41
  • 2
    @q126y What you are describing looks more like Factory of Builders. Actually, wouldn't Builder pattern be better than Factory?
    – Euphoric
    Commented Nov 27, 2015 at 15:40
  • yes, builder would be better for more granularity.
    – q126y
    Commented Dec 4, 2015 at 6:00

A single BikeFactory should be able to produce different Bikes - so a user chooses a red Harley with a teddy bear on the handlebar. You simple need two arguments to your BikeFactory::createBike - the bike type, and the options (red paint, and handlebar decoration).

Your BikeFactory then creates a Harley, and injects the options into that instance of Harley.

You don't need a specific Harley factory - Harleys are built the same as Suzukis/Hondas/Sanchezes.

  • But you can have a factory that makes objects that themselves make other things in the real world. I bet you could even have a factory that makes 3D printers, and then use one of these printers to make another object that makes something else.
    – user82096
    Commented Nov 27, 2015 at 13:53
  • @dan1111 - 3D printers can even make more 3D printers ;) in any event - while in the real world you have factories that create more factories, in programming you'd have strategies to determine the appropriate factory to build a bike/car/printer.
    – HorusKol
    Commented Nov 27, 2015 at 14:28
  • 1
    While I won't say that a factory of factories would never be a good idea, I also think that the brain likes to fit things into neat little packages, and it almost rarely does fit into neat little packages. And using patterns when patterns shouldn't be used is never a smart idea. Factory should in theory do everything that a factory of factories could do. Your program should never get to be that complicated to need it.
    – Neil
    Commented Nov 27, 2015 at 14:33
  • 2
    @q126y If you need fine-tuned control over the types of vehicles, you'd have a buildCar and buildMotorcycle and buildTruck with parameters. If you don't care about these things, then maybe you'd just see "createRandomVehicle" with no parameters. The factory deals with statistics and stylings. That is probably how I'd go about it anyway.
    – Neil
    Commented Nov 27, 2015 at 14:46
  • 1
    @q126y The fact that it is its own library should tell you that it isn't something you would just do casually in your program. It'd be like building your own database because you needed to use one in you program, with the difference being that a FoF is adding complexity that may not even be necessary. Again, I don't mean to say it is impossible that you'd need to use it, but you should take a long hard look at your program before you decide to do so.
    – Neil
    Commented Dec 4, 2015 at 14:56

Not the answer you're looking for? Browse other questions tagged or ask your own question.