工厂设计模式可解决哪些问题？通用与独有行为场景该选它还是普通类？

• 解耦对象创建与业务逻辑：避免在业务代码中硬编码具体类的实例化逻辑（比如new WeChatPay()），业务层只依赖抽象接口，后续替换实现类时无需修改业务代码。比如日志模块，业务只需调用Logger接口的log()方法，具体是文件日志还是数据库日志由工厂决定。
• 集中管理复杂的对象初始化：如果创建对象需要多步配置（比如数据库连接的驱动加载、连接池参数设置），工厂可以把这些重复逻辑统一封装，避免代码冗余。
• 隐藏对象创建细节：调用方无需关心具体类的构造参数、内部状态，只需告知工厂所需对象的类型或条件，就能拿到可用实例。比如要一个支付处理器，不用管微信支付的appId、密钥怎么配置，工厂直接返回初始化好的实例。
• 支持动态对象创建：可以根据运行时参数（比如用户配置、请求参数）动态生成不同的实例。比如根据用户选择的地区，创建对应语言的国际化文案实例。

• 从简单工厂模式入手，别一开始就啃抽象工厂。简单工厂逻辑直白：一个工厂类负责创建多个相关类的实例，比如写一个ShapeFactory，传入"circle"就返回Circle实例，传入"square"就返回Square实例，先跑通这个最小模型。
• 明确抽象层与实现层的边界：先定义抽象接口/抽象类（比如Shape有draw()方法），再写具体实现类，最后让工厂类依赖抽象层，返回抽象类型的实例。这样能清晰看到每个角色的职责。
• 写极简可运行Demo：别搞复杂场景，先实现2-3个具体类的小例子，比如控制台日志和文件日志的工厂，一步步写代码，观察工厂如何隔离创建逻辑。
• 对照书中类图写代码：把《Design Patterns》里的类图转换成实际代码，逐个对应角色（抽象产品、具体产品、工厂），理解每个部分的作用。

核心看对象的创建需求：

• 选工厂模式的场景：如果需要运行时动态选择具体实现（比如根据用户输入生成不同的实例），或者未来会扩展更多同类对象（比如现在有Dog和Cat，以后要加Bird），用工厂模式更合适。比如定义Animal抽象类，通用行为eat()放在抽象类里，独有行为makeSound()由具体类实现，工厂根据参数返回对应实例，业务层只和Animal交互。
• 选普通类的场景：如果对象数量固定、不需要动态创建，直接实例化普通类即可。比如只有Car和Bike，通用行为move()抽成接口，各自实现独有行为honk()和ringBell()，业务代码直接new Car()调用，没必要引入工厂增加复杂度。

不管选哪种，都应该把通用行为抽成抽象类或接口，实现代码复用，这是面向对象的基础操作，和用不用工厂无关。

内容的提问来源于stack exchange，提问作者Deepak Atariya