I am programming a game. In this game I have 3 stages. In the first stage, there is a static goal and a static shooter in the game. In the second stage, the goal will move. And in the third one both are moving.

I want to use abstract factory to create objects of same family.

I want to know which of the following designs is right:

With 2 factories:

with 2 factories

With 3 factories:

with 3 factories

I just don't know whether I should make concrete factories in the same count of families at the right hand or according to my problem?

For example, in the scenario, I have two families of objects (Products). First family is Gun and the second is Goal. But I have 3 stages that I have explained above. Is it right to have 2 factories because of the count of families of products or to have 3 families according to the stages?

  • I have explained it more. – ConductedClever Dec 12 '14 at 19:34
  • 2
    What problem are you trying to solve by using these factories? – Doval Dec 12 '14 at 20:03
  • i want to solve the creational problem. the creating part of the problem for different products are complicated. with this design pattern , i want to mask this part. i want the factories to do this for me. sourcemaking.com/design_patterns/abstract_factory – ConductedClever Dec 12 '14 at 20:31
  • Both approaches solve the problem of objects being complicated to construct. – Doval Dec 12 '14 at 20:42
  • 1
    there was a little mistake in the second picture. i have changed it. – ConductedClever Dec 13 '14 at 3:25

To be honest, I'd probably take a different approach entirely. I'd build 4 factories, one for each object type. I'd then create a new Level class that contains one instance of a GunFactory and one of a GoalFactory, and I would create 3 instances of Level (probably stored in a List) each having the appropriate combination of factory.

There are two reasons for this, one theoretical and one practical. On a theoretical level, it is not at all clear that the responsibilities "create a gun" and "create a goal" are part of the same responsibility, so the Single Responsibility Pattern states that we should avoid having a single object that doesboth. The Level object on the other hand does have one clear responsibility: "hold together all of the information and behavior necessary to initialize a level of the game".

The second, more practical aspect, is that this lets you add new levels more easily than either of your original suggestions. Say you want to add a fourth level that uses a different combination of gun and goal again; in your first design you would have to change your existing initialization code to pick a different set of factories, in the second you'd have to create a new subclass of your abstract factory class, whereas with my suggestion you'd just add a new Level instance to the list, a single line change. (This could also be phrased theoretically as "the design is more compliant with the open/closed principle when levels need to be added", but I prefer the practical emphasis here).

  • 1
    As an aside, I've avoided using the term "stage" here to avoid confusion with a design pattern common in games in which visible objects are called "Actors" and are arranged on an object called the "Stage". If you expect your code to be read by anyone who might be used to this terminology, I'd suggest doing the same in order to avoid potential confusion. – Jules Dec 13 '14 at 10:37
  • And how would you represent the list you mentioned, in the class diagram? – ConductedClever Dec 13 '14 at 10:49
  • It would be a property of whichever class is responsible for using the factories currently (i don't believe this class is currently shown in your diagrams). – Jules Dec 13 '14 at 12:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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