网站首页包含的内容,如何做推广呢,申报网站,wordpress the7 汉化工厂方法模式是一种创建型设计模式#xff0c;它提供了一种创建对象的接口#xff0c;但将具体实例化对象的工作推迟到子类中完成。这样做的目的是创建对象时不用依赖于具体的类#xff0c;而是依赖于抽象#xff0c;这提高了系统的灵活性和可扩展性。 以下是工厂方法模式的… 工厂方法模式是一种创建型设计模式它提供了一种创建对象的接口但将具体实例化对象的工作推迟到子类中完成。这样做的目的是创建对象时不用依赖于具体的类而是依赖于抽象这提高了系统的灵活性和可扩展性。 以下是工厂方法模式的几个关键组成部分 产品Product: 定义了工厂方法所创建的对象的接口。在我们的日志记录器示例中Logger 类就是一个产品接口。 具体产品Concrete Product: 实现了产品接口的具体类。继承自Logger类的FileLogger、ConsoleLogger 和 DatabaseLogger类就是具体产品。 创建者Creator: 声明了工厂方法这个方法返回一个产品类型的对象。通常情况下创建者类将是抽象类并包含工厂方法的声明。在我们的示例中LoggerFactory就是一个创建者。 具体创建者Concrete Creator: 覆盖了工厂方法以返回一个具体产品实例。这是实际决定要实例化哪一个产品的类。例如FileLoggerFactory、ConsoleLoggerFactory 和 DatabaseLoggerFactory都是具体创建者它们覆盖工厂方法以返回它们各自的产品实例。 工厂方法模式的工作方式: 定义产品接口: 首先定义一个产品接口它描述了产品的公共接口。创建具体产品: 然后为每种类型的产品实现具体类。创建抽象创建者: 接着创建一个创建者通常是抽象类或接口来声明工厂方法。工厂方法通常会有一个返回类型为产品接口的返回类型。实现具体创建者: 创建具体创建者类来实现抽象创建者中声明的工厂方法返回具体产品的实例。在应用中使用创建者: 最后在应用程序中我们使用创建者类来调用工厂方法获取产品对象的实例。 工厂方法模式的优点: 降低耦合度: 客户代码从具体类解耦并依赖于抽象。这意味着客户代码不需要改变就能与任何新增的具体产品工作。增加了系统的可扩展性: 新的具体产品可以很容易地加入到系统中因为现有的客户代码不会受到影响。提高代码的可维护性: 如果一种产品在多处创建更改产品的实现或者更换一个产品都会更加容易和集中。 工厂方法模式的缺点: 增加了代码的复杂性: 可能需要引入许多新类每种类型的产品都需要一个新的具体创建者类。需要更多的设计考虑: 设计好抽象创建者和具体创建者之间的关系需要一定的设计经验和考虑。 总的来说工厂方法模式在需要灵活和可扩展的系统中非常有用尤其是当我们预计产品类可能会经常改变时。它有助于保持一个健壮而灵活的代码库。 目录
一、案例
1.1 示例代码
1.2 扩展-添加数据库日志
二、模式讲解
2.1 功能
2.2 工厂方法模式结构
2.3 示例代码程序结构图
2.4 简单工厂方法结构图
2.5 工厂方法模式与简单工厂模式
三、扩展-工厂方法与IoC/DI 3.1 弄明白IoC/DI 3.2 工厂方法与IoC/DI的关系 一、案例 场景 需要一个创建不同类型日志记录器的框架日志记录器可能记录到文件、控制台或者数据库。 1.1 示例代码 定义一个抽象日志记录器类和一个工厂方法
/*** 日志处理抽象类*/
public abstract class Logger {/*** 操作日志*/public abstract void log(String message);
}/*** 工厂方法抽象类*/
public abstract class LoggerFactory {/*** 操作日志*/public void log(String message) {createLogger().log(message);}/*** 工厂方法创建日志对象的接口对象*/public abstract Logger createLogger();
} 为文件日志类型实现具体的日志记录器和对应的工厂
/*** 文件日志实现类*/
public class FileLogger extends Logger {public void log(String message) {// 逻辑来将消息写入文件System.out.println(File logger: message);}
}/*** 文件日志工厂方法类*/
public class FileLoggerFactory extends LoggerFactory {Overridepublic Logger createLogger() {// 可以在这里添加创建FileLogger所需的逻辑和初始化return new FileLogger();}
} 为控制台日志类型实现具体的日志记录器和对应的工厂
/*** 控制台日志实现类*/
public class ConsoleLogger extends Logger {public void log(String message) {// 逻辑来将消息打印到控制台System.out.println(Console logger: message);}
}/*** 控制台工厂方法类*/
public class ConsoleLoggerFactory extends LoggerFactory {Overridepublic Logger createLogger() {// 创建ConsoleLogger的逻辑return new ConsoleLogger();}
} 现在在应用程序中我们可以根据需要使用工厂来创建日志记录器对象而不必直接实例化它们。这样如果以后需要添加新的日志记录器类型例如数据库日志记录器我们只需要添加一个新的工厂而不需要修改现有代码。 客户端示例代码
public class Application {public static void main(String[] args) {LoggerFactory factory new FileLoggerFactory();// 或者 factory new ConsoleLoggerFactory();factory.log(这是一条日志信息.);}
} 当 Application 运行时根据选择的工厂类型它将使用对应的工厂创建一个日志记录器并通过这个记录器记录消息。这个示例遵循了工厂方法的设计原则因为它使对象的创建和使用分离使得系统易于扩展和维护。 1.2 扩展-添加数据库日志 如果我们想要将日志记录扩展到数据库我们首先需要为数据库日志创建一个新的Logger子类然后实现对应的工厂类。下面展示了如何实现这一扩展:
// 数据库日志记录器——实现Logger抽象类
public class DatabaseLogger extends Logger {public void log(String message) {// 示例逻辑来将消息保存到数据库System.out.println(Database logger: message);// 这里可以包含实际将日志保存到数据库的代码}
}// 数据库日志工厂——继承LoggerFactory
public class DatabaseLoggerFactory extends LoggerFactory {Overridepublic Logger createLogger() {// 创建DatabaseLogger的逻辑可以在这里包含初始化代码return new DatabaseLogger();}
} 在Application 或其他任何需要日志记录功能的部分现在可以不作出太多改动地简单地引入新的DatabaseLogger:
public class Application {public static void main(String[] args) {LoggerFactory factory new DatabaseLoggerFactory();// 或者 factory new FileLoggerFactory();// 或者 factory new ConsoleLoggerFactory();factory.log(这是一条日志信息.);}
} 现在无论是FileLoggerFactory、ConsoleLoggerFactory还是DatabaseLoggerFactory均不需要修改 Application 中的任何代码。进一步说如果有必要添加其他类型的日志记录如远程API日志记录、XML日志记录等整个流程同样适用。这就展示了工厂方法模式在扩展性方面的强大之处。每次新增一种产品本例中的Logger实现只需添加一个新的具体工厂类且不需要改动现有的代码符合开闭原则对修改封闭对扩展开放。 通过上述示例你可以看到工厂方法设计模式是如何工作的它能够提供足够的灵活性允许系统在不直接依赖具体类的情况下创建对象。这种方式降低了类间的耦合提高了代码的可维护性与可扩展性。 二、模式讲解
2.1 功能 功能工厂方法主要工能是让父类在不知道具体实现的情况下完成自身的功能调用而具体的实现延迟到子类来实现。 这样在设计的时候不用去考虑具体的实现需要某个对象把它通过工厂方法返回就好了 在使用这些对象实现功能的时候还是通过接口来操作这类似于 IoC/DI 的思想。 2.2 工厂方法模式结构 Logger定义工厂方法所创建的对象的类也就是实际需要使用的对象的类。子类A具体的 Logger 接口的实现对象。Factory创建器声明工厂方法工厂方法通常会返回一个 Logger 类型的实例对象而且多是抽象方法。也可以在 Factory里面提供工厂方法的默认实现让工厂方法返回一个缺省的Logger类型的实现对象。实现类B具体的创建器对象覆盖实现 Factory 定义的工厂方法返回具体的 Logger实例。 2.3 示例代码程序结构图 2.4 简单工厂方法结构图 2.5 工厂方法模式与简单工厂模式 工厂方法模式与简单工厂模式结构如上图2 和 图3。 简单工厂模式见探索设计模式的魅力简单工厂模式-CSDN博客文章浏览阅读1.5k次点赞50次收藏36次。实现简单工厂的难点就在于 “如何选择” 实现前面便子中传递参数的方法 那都是静态的参数还可以实现成为动态的参数。客户端通过简单工厂创建 了一个实现接口的对象然后面向接口编程从客户端来看它根本不知道具体的实现是什么也不知道是如何实现的它只知道通过工厂获得了一个接口对象 然后通过这个接口来获取想要的功能。如果通过客户端的参数来选择具体的实现类那么就必须让客户端能理解各个参数所代表的具体功能和含义这样会增加客户端使用的难度也部分暴露了内部实现这种情况可以选用可配置的方式来实现。https://blog.csdn.net/danci_/article/details/135566105 若要添加新的日志类型简单工厂模式需要添加这个新功能类的日志子类再在Factory中添加一个case语句来做判断工厂方法模式需要添加这个新功能类的日志子类再添加一个实现Factory的工厂类。但要我再去更改客户端这 不等于不但没有减化难度反而增加了很多类和方法把复杂性增加了 吗?为什么要这样?” 简单工厂模式最大优点在于工厂类中包含了必要的逻辑判断根据客户端的选择条件动态实例化相关的类对于客户端来说去除了与具体产品的依赖。但是如果添加新的日志类型就要去个性case判断条件这违背了开-闭原则。工厂类扩展了也修改了 于是工厂方法出现了。 工厂方法模式Factory Method定义一个用于创建对象的接口让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。 此时添加新的日志类型只需要添加新的日志子炻和新的日志工厂类满足了开-闭原则。对扩展开放对修改关闭 三、扩展-工厂方法与IoC/DI IOC-Inversion of Control控制反转。 DI-Dependency Injection依赖流入。 3.1 弄明白IoC/DI 1. 参与者一般有三方参与者一个是某个对象;另一个是IoC/DI 的容器;还有一个是某个对象的外部资源。 2. 谁依赖于谁 当然是某个对象依赖于 IoC/DI 的容器。 3. 为什么需要依赖对象需要 IoC/DI 的容器来提供对象需要的外部资源。 4. 谁注入于谁很明 显是 IoC/DI 的容器注入某个对象。 5. 到底注入什么就是注入某个对象所需要的外部资源。 6. 谁控制谁当然是 IoC/DI 的容器来控制对象了。 7. 控制什么主要是控制对象实例的创建。 8. 为何叫反转 : 反转是相对于正向而言的那么什么算是正向的呢? 考虑一下常规情况下的应用程序如果要在A 里面使用C你会怎么做呢? 当然是直接去创建C 的对象也就是说在A 类中主动去获取所需要的外部资源C这种情况被称为正向的。 那么什么是反向呢?就是A 类不再主动去获取C而是被动等待等待IoC/DI 的容器获 取一个C的实例然后反向地注入到A 类中。 9. 依赖注入和控制反转是同一概念吗 依赖注入和控制反转是对同一件事情的不同描述。 从某个方面讲就是它们描述的角度不同。依赖注入是从应用程序的角度去描述可以 把依赖注入描述得完整点 :应用程序依赖容器创建并注入它所需要的外部资源;而控制 反转是从容器的角度去描述描述得完整点就是 :容器控制应用程序由容器反向地向 应用程序注入其所需要的外部资源。 小结:其实 IoC/DI 对编程带来的最大改变不是在代码 上而是在思想上发生了“主从换位”的变化。应用程序原本是老大要获取什么资源都是主动出击 但是在 IoC/DI 思想中应用程序就变成被动的了被动地等待 IoC/DI 容器来创建并注入它所需要的资源了。 3.2 工厂方法与IoC/DI的关系 IoC/ DI主从换位被动等待IOC/DI容器来创建并流入它所需要的资源。 工厂方法
/*** 工厂方法抽象类*/
public abstract class LoggerFactory {/*** 操作日志*/public void log(String message) {createLogger().log(message);}/*** 工厂方法创建日志对象的接口对象*/public abstract Logger createLogger();
} log方法中需要用Logger类可是又不知道要用哪一个也不去主动去创建了反正在子类里已经实现了不用管怎么获取直接使用日志功能类似于从子类注入进来。 从思想层面上会发现工厂方法示模式和 IoC/DI 的思想是相似的都是“ 主动变被动” 进行了“ 主从换位” 从而获得了更灵活的程序结构。
