There’re too many classes (and too much code in general), coupled very tightly to each other. The example code is very error prone. These string item names are

There’re too many classes (and too much code in general), coupled very tightly to each other. The example code is very error prone. These string item names are easy to mistype, the compiler will OK that, if you’re lucky you’ll find a runtime error, otherwise you’ll introduce the bug. Enums are usually better. That “code likely/unlikely to change” stuff is just a guess. If neither of them changes, the proposed approach introduced a lot of complexity for no value. But if the “code likely to not change” ever changes (e.g. extra steps dependent on pizza or store), the proposed approach won’t work at all, it’s either redesign or hacks. Personally, 80% of times I used factory pattern was while implementing deserializers (esp. in C++ that lacks reflection). The other 20% is when I instantiated concrete classes based on come config values of user input. Oh, and all my class factories were just functions, there’s no need for separate factory classes.