高频工厂模式面试题及答案

高频工厂模式面试题及答案请描述工厂模式的核心思想及其解决的问题？工厂模式的核心思想是将对象的创建逻辑从业务代码中剥离，通过专门的工厂类或接口来封装对象的实例化过程。其核心目的是解决对象创建与使用的强耦合问题，使系统在扩展新对象类型时，尽可能减少对现有代码的修改，提高代码的可维护性、可扩展性和可测试性。具体来说，当业务逻辑中需要频繁创建不同类型的对象（尤其是这些对象属于同一产品等级结构或产品族）时，直接通过new关键字实例化会导致创建逻辑分散在代码各处，一旦对象的构造参数、初始化逻辑或类型需要调整，所有调用处都需要修改，违反“开闭原则”。工厂模式通过将创建逻辑集中到工厂类中，使对象的使用者只需关注如何使用对象，而无需关心对象如何被创建，同时为后续扩展新的产品类型提供了标准化的扩展点。简单工厂模式、工厂方法模式、抽象工厂模式的具体实现差异是什么？简单工厂模式（SimpleFactoryPattern）：通过一个工厂类的静态或实例方法，根据传入的参数（如类型标识）动态决定创建哪一种产品类的实例。其结构包含抽象产品接口、具体产品类和一个工厂类。例如，定义支付接口Pay，具体实现类AliPay、WeChatPay，工厂类PayFactory提供createPay(Stringtype)方法，根据type参数返回对应的支付实例。简单工厂的核心是“用一个工厂处理多种产品的创建”，但所有产品的创建逻辑集中在同一个工厂类中，当需要添加新产品时，必须修改工厂类的判断逻辑，违反“开闭原则”。工厂方法模式（FactoryMethodPattern）：将对象的创建延迟到具体工厂子类中，通过定义抽象工厂接口和具体工厂类来解决简单工厂的缺陷。其结构包含抽象产品接口、具体产品类、抽象工厂接口（声明创建产品的方法）和具体工厂类（实现抽象工厂接口，创建具体产品）。例如，定义日志记录接口Logger，具体实现类FileLogger、DbLogger；同时定义抽象工厂接口LoggerFactory，具体工厂类FileLoggerFactory、DbLoggerFactory分别实现createLogger()方法，返回对应的Logger实例。工厂方法的核心是“每个产品对应一个工厂”，当需要添加新产品时，只需新增具体产品类和对应的具体工厂类，无需修改现有工厂接口和其他工厂类，符合“开闭原则”。抽象工厂模式（AbstractFactoryPattern）：用于创建相关或依赖的产品族（即一组在不同维度上关联的产品），而不仅仅是单一产品。其结构包含抽象产品族接口（如抽象产品A、抽象产品B）、具体产品族实现（如产品A1、产品A2，产品B1、产品B2）、抽象工厂接口（声明创建所有产品族中产品的方法）、具体工厂类（实现抽象工厂接口，创建某一具体产品族的所有产品）。例如，跨平台UI组件开发中，抽象工厂接口定义createButton()、createDialog()方法；Windows工厂实现类创建Windows风格的按钮和对话框，Mac工厂实现类创建Mac风格的按钮和对话框。抽象工厂的核心是“一个工厂负责创建一个产品族的所有产品”，适用于需要保证产品族内产品兼容（如同一风格）的场景，但扩展新的产品等级结构（如新增滚动条组件）时，需要修改所有抽象工厂和具体工厂类，违反“开闭原则”。简单工厂模式是否符合“开闭原则”？为什么？如何改进？简单工厂模式不符合“开闭原则”。开闭原则要求“对扩展开放，对修改关闭”，即当新增功能时，应通过扩展现有代码而非修改现有代码实现。在简单工厂中，工厂类负责根据参数判断创建哪种产品实例。当需要添加新的产品类型时，必须修改工厂类的创建方法（如新增一个case分支或if-else判断），这直接违反了开闭原则。例如，原有PayFactory支持AliPay和WeChatPay，若新增UnionPay，需要在createPay方法中添加对"union"类型的判断，修改了原有的工厂类逻辑。改进方法是引入工厂方法模式。工厂方法模式将产品的创建逻辑分散到不同的具体工厂类中，每个具体产品对应一个具体工厂。当需要新增产品时，只需创建新的具体产品类和对应的具体工厂类，无需修改原有的抽象工厂接口和其他具体工厂类。例如，将PayFactory改为抽象工厂接口，定义createPay()方法，然后为AliPay、WeChatPay、UnionPay分别创建AliPayFactory、WeChatPayFactory、UnionPayFactory具体工厂类。新增UnionPay时，只需实现UnionPay类和UnionPayFactory类，原有工厂接口和其他工厂类保持不变，符合开闭原则。工厂方法模式中，抽象工厂与具体工厂的职责分别是什么？它们如何协作完成对象创建？抽象工厂的职责是定义创建产品的接口（即声明创建产品的抽象方法），它不负责具体产品的实例化，而是由其子类（具体工厂）实现该接口。抽象工厂的存在为所有具体工厂提供了统一的创建产品的规范，使得客户端可以通过抽象工厂接口调用产品创建方法，而无需关心具体是哪个工厂类在执行创建。具体工厂的职责是实现抽象工厂接口中声明的创建方法，负责具体产品的实例化。每个具体工厂对应一种具体产品，当需要创建某类产品时，客户端选择对应的具体工厂实例，调用其创建方法即可得到目标产品。协作流程示例：假设需要实现数据库连接工厂，抽象工厂接口定义为DatabaseFactory，包含createConnection()方法；具体工厂类MySqlFactory、OracleFactory分别实现该接口，createConnection()方法返回MySqlConnection和OracleConnection实例。客户端代码通过依赖注入或配置获取具体的DatabaseFactory（如MySqlFactory），调用其createConnection()方法，即可得到对应的数据库连接对象。这种协作方式将产品的创建逻辑封装在具体工厂中，客户端只需与抽象工厂和抽象产品交互，实现了客户端与具体产品的解耦。抽象工厂模式中的“产品族”指什么？它与工厂方法模式的核心区别是什么？“产品族”指的是位于不同产品等级结构中，但由同一工厂创建的一组相关或依赖的产品。例如，华为的产品族可能包括手机、平板、耳机（属于不同的产品等级结构：手机是通信设备，平板是移动终端，耳机是音频设备），但这些产品由华为工厂统一设计，具有风格或功能上的一致性（如生态互联）。再如，跨平台UI组件中，Windows风格的按钮、文本框、对话框属于同一产品族，由Windows工厂创建；Mac风格的对应组件属于另一产品族，由Mac工厂创建。工厂方法模式与抽象工厂模式的核心区别体现在解决的问题维度上：1.产品数量维度：工厂方法模式解决的是单一产品等级结构的创建问题（即一个产品类型，多个具体实现），例如日志记录器（FileLogger、DbLogger）；而抽象工厂模式解决的是多个产品等级结构（即多个产品类型）的产品族创建问题，例如UI组件中的按钮、文本框、对话框（每个都是独立的产品等级结构，但需要同一风格）。2.扩展方向不同：工厂方法模式支持扩展新的产品类型（即新增产品等级结构的具体实现），只需新增具体产品类和对应的具体工厂类，符合开闭原则；而抽象工厂模式支持扩展新的产品族（即新增同一产品等级结构下的不同风格实现），例如新增Linux风格的UI组件，只需新增Linux工厂类并实现所有产品的创建方法，无需修改现有代码。但抽象工厂模式对扩展新的产品等级结构（如新增滚动条组件）不友好，需要修改抽象工厂接口及所有具体工厂类的实现，违反开闭原则。3.工厂职责不同：工厂方法模式中，每个具体工厂只创建一种具体产品；抽象工厂模式中，每个具体工厂需要创建一个产品族中的所有产品（如Windows工厂需创建Windows按钮、Windows文本框等）。实际开发中，如何选择使用简单工厂、工厂方法或抽象工厂模式？选择依据主要基于业务场景的复杂度和扩展性需求：简单工厂：适用于产品类型较少（通常不超过3种）、且未来扩展可能性低的场景。例如，系统中需要根据配置文件中的类型标识创建不同的支付方式（如支付宝、微信支付），且短期内不会新增其他支付方式。此时简单工厂的代码量少、逻辑集中，维护成本较低。但需注意，若后续可能频繁新增产品类型，简单工厂会导致工厂类不断膨胀，此时应考虑升级为工厂方法模式。工厂方法：适用于产品类型较多（超过3种）或未来需要频繁扩展新的产品类型的场景。例如，日志框架需要支持文件日志、数据库日志、网络日志等，且后续可能新增云存储日志等类型。工厂方法通过为每个日志类型提供独立的工厂类，确保新增日志类型时只需添加新类，无需修改现有代码，符合开闭原则。抽象工厂：适用于需要创建一组相关或依赖的产品（产品族），且需要保证产品族内产品兼容性的场景。例如，开发跨平台的GUI应用，需要确保同一平台下的按钮、窗口、菜单等组件风格一致（如Windows风格或Mac风格）。此时抽象工厂可以保证同一工厂创建的组件属于同一风格，避免不同风格组件混用导致的兼容性问题。另一个典型场景是ORM框架中的方言适配，不同数据库（MySQL、Oracle）需要不同的SQL语法解析器、连接池配置等，抽象工厂可以统一创建某一数据库对应的所有适配组件。工厂模式如何体现面向对象设计原则？请结合具体模式说明。工厂模式主要体现了以下面向对象设计原则：1.依赖倒置原则（DIP）：高层模块（客户端）不应该依赖低层模块（具体产品类），而应依赖抽象（抽象产品接口和抽象工厂接口）。例如，在工厂方法模式中，客户端通过抽象工厂接口调用createProduct()方法，得到的是抽象产品接口类型的实例，客户端只需与抽象交互，无需依赖具体产品类的实现。这降低了客户端与具体实现的耦合。2.开闭原则（OCP）：工厂方法模式和抽象工厂模式通过扩展具体工厂类来支持新的产品类型或产品族，而无需修改现有工厂接口和客户端代码。例如，新增一个具体产品时，只需添加对应的具体产品类和具体工厂类，客户端通过配置或反射切换工厂实例即可使用新产品，原有代码保持不变。3.单一职责原则（SRP）：工厂类（或接口）仅负责对象的创建，业务逻辑类仅负责对象的使用，将对象的创建职责与使用职责分离。例如，订单处理类只需调用支付接口的pay()方法完成支付，无需关心支付对象是如何创建的（是支付宝还是微信支付），创建职责由工厂类承担。4.迪米特法则（LoD）：客户端只需知道抽象工厂和抽象产品的存在，无需了解具体产品的构造细节（如构造参数、初始化逻辑）。例如，客户端通过工厂获取数据库连接时，无需知道连接需要哪些URL、用户名、密码等参数，这些参数由工厂内部处理，客户端与具体产品的细节解耦。以工厂方法模式为例，假设客户端需要记录日志，抽象产品是Logger接口（定义log(Stringmessage)方法），具体产品是FileLogger、DbLogger；抽象工厂是LoggerFactory接口（定义createLogger()方法），具体工厂是FileLoggerFactory、DbLoggerFactory。客户端代码只需要通过LoggerFactory获取Logger实例并调用log()方法，无需知道FileLogger的文件路径如何配置、DbLogger的数据库连接如何建立，这些细节由具体工厂封装，体现了依赖倒置、单一职责和迪米特法则。实际项目中，工厂模式可能遇到哪些问题？如何解决？1.工厂类膨胀问题：在工厂方法模式中，每个具体产品对应一个具体工厂类，当产品类型过多时，工厂类的数量会急剧增加，导致类爆炸。例如，若系统中有100种不同的日志类型，就需要100个具体工厂类，增加了项目的维护成本。解决方法：可以结合简单工厂模式进行优化，将工厂方法模式中的具体工厂类通过反射或配置的方式动态创建。例如，定义一个通用的LoggerFactory，通过读取配置文件中的“产品类型-工厂类”映射关系，使用反射动态实例化对应的具体工厂类，再调用其createLogger()方法。这样可以减少工厂类的数量，同时保持扩展性。2.抽象工厂模式的扩展困难：抽象工厂模式难以扩展新的产品等级结构（如新增产品类型）。例如，原有抽象工厂接口定义了createButton()、createDialog()方法，若需要新增createScrollBar()方法，所有具体工厂类都需要实现该方法，违反开闭原则。解决方法：在设计抽象工厂接口时，需充分评估未来可能的产品等级结构扩展，预留扩展点。例如，若预计未来可能新增滚动条组件，可在抽象工厂接口中预先定义createComponent(Stringtype)方法，通过类型参数动态创建不同类型的组件，将具体的创建逻辑延迟到具体工厂中处理。但这种方法会引入一定的类型判断逻辑，需权衡灵活性与简洁性。3.工厂与产品的版本一致性问题：当产品的实现发生较大变更（如构造函数参数变化）时，对应的工厂类也需要同步修改，可能导致工厂与产品之间的紧耦合。解决方法：通过接口或抽象类隔离产品的变化。例如，产品类的构造函数参数变化时，只要其接口（如log()方法）保持不变，工厂类只需调整内部创建逻辑（如获取新的参数），客户端无需感知。此外，可以引入构建器模式（BuilderPattern）与工厂模式结合，将产品的复杂构造过程封装到构建器中，工厂类通过调用构建器来创建产品，降低工厂与产品构造细节的耦合。Spring框架中的BeanFactory是否属于工厂模式？请结合源码说明其实现方式。Spring的BeanFactory属于工厂模式的典型应用，其核心职责是管理Bean的创建、配置和依赖注入，本质上是一个通用的工厂框架。BeanFactory通过定义统一的接口（如org.springframework.beans.factory.BeanFactory），允许不同的具体工厂（如XmlBeanFactory、AnnotationConfigApplicationContext）根据配置（XML、注解）创建和管理Bean实例，符合工厂模式“通过抽象工厂创建具体产品”的核心思想。以BeanFactory的getBean()方法为例，其方法签名为ObjectgetBean(Stringname)throwsBeansException，该方法类似于工厂模式中的createProduct()方法，根据Bean的名称（或类型）返回对应的Bean实例。具体工厂类（如DefaultListableBeanFactory）负责解析Bean定义（如XML中的<bean>标签或注解@Bean），并根据定义信息