In the explanation of the AbstractFactory pattern, we often see examples of passing a character string as a runtime argument or making an if-else judgment with a flag.

In personal development, you may not care because you know everything. However, if it is provided as a module to other teams in team development, How do you know which Factory the team that received the Factory can generate?

I think the method is either to check the code yourself or to check with the person in charge of the code on the Factory side.

The person in charge on the Factory side, whether for the code person in the client, Whether it's because it's a hassle to answer when you come to ask yourself ** Please be aware that "Enums can clearly show what can be generated" **.

Factroy generation method that you often see

Code example to judge by passing the class name as a character string

I think this has the following problems. ・ Is it possible to say that the specified character strings are not different? ・ Is it possible that the case is correct? ・ Isn't it possible to call a Factory that does not exist in the first place?

Example of determining the Factory to be generated by the flag

I think this has the same problem as the string case. Also, under this judgment condition, FactroyY is generated for everything except 0, It includes the possibility that Factory Y will be generated unexpectedly.

Example using Enum

When implemented using Enum, it explicitly indicates the Factroy to be generated, and it will not generate a Factory that does not exist. * The following code is my own improvement of the TECH SCORE Abstract Factory pattern. Please include that it has nothing to do with TECH SCORE. </ span> 8. AbstractFactory pattern

Use.java (client) It is generated by specifying Recipe (Factory class) in HotpotType which is Enum.

HotpotType.java (Enum to generate Factory) The Factory that can be generated is defined here. If you specify Sukiyaki, Sukiyaki Recipe will be generated.

Recipe.java (Factory class) Factory generation is delegated to HotpotType, so you can concentrate on the abstract implementation only.

Benefits of generating with Enum

-Since only Factroy existing in Enum can be generated, an erroneous Factory will not be generated. -For team development, the client-side code manager does not need to know what the Factory class can be generated. If the Factory class is missing, all you have to do is ask the programmer in charge of the Factory side. -Easy to add Factory. Since you only need to add the required Factory class to the Enum, there is no need to modify the if statement.

If you write the program by yourself, you don't have to think about this, but ** If you work as a team and you are in charge of dividing modules By thinking in this way, the ease of change can be improved and modularization can be facilitated. ** **

Class diagram

Github

https://github.com/TakumiKondo/designpattern/tree/master/src/abstractfactory/hotpot

Advantages of generating an Abstract Factory pattern with an enum