GoF设计模式——工厂方法模式
h5打开以查看为什么需要简单工厂模式?假设在开发一个通知系统,最初只支持邮件通知:Notification n = new EmailNotification(); n.send("欢迎注册");简单直接,没毛病。后来产品加了短信通知,代码变成了这样:// 订单模块 if (type.equals("email")) { n = new EmailNotification(); } else if (type.equals("sms")) { n = new SmsNotification(); } n.send("订单已提交"); // 用户模块 if (type.equals("email")) { n = new EmailNotification(); } else if (type.equals("sms")) { n = new SmsNotification(); } n.send("注册成功"); // 营销模块 if (type.equals("email")) { n = new EmailNotification(); } else if (type.equals("sms")) { n = new SmsNotification(); } n.send("限时优惠来袭");同一段if-else复制粘贴到十个地方。产品说"把默认通知方式改成短信",得满世界找,改漏一个就是线上 bug。这就是选择逻辑散落的痛——不是构造有多复杂,而是同样的判断写了十遍,改一处容易,改十处就要命。很自然的想法:把选择逻辑收拢到一个地方,客户端只告诉工厂"我要什么":public class NotificationFactory { public static Notification create(String type) { if ("email".equals(type)) { return new EmailNotification(); } else if ("sms".equals(type)) { return new SmsNotification(); } else { throw new IllegalArgumentException("未知的通知类型: " + type); } } }现在改默认通知方式?改工厂一处就行。问题暂时解决了。✅为什么需要工厂方法模式?好景不长,产品要加微信、钉钉、站内信……每新增一种,就得打开工厂往里塞else if:public static Notification create(String type) { if ("email".equals(type)) { return new EmailNotification(); } else if ("sms".equals(type)) { return new SmsNotification(); } else if ("wechat".equals(type)) { return new WechatNotification(); } else if ("dingtalk".equals(type)) { return new DingtalkNotification(); } else if ("inbox".equals(type)) { return new InboxNotification(); } else { throw new IllegalArgumentException("未知的通知类型: " + type); } }工厂从5行膨胀到几十行,每次改动都有引入 bug 的风险。问题出在哪?简单工厂把"判断创建哪种"和"执行创建"绑死在一个类里,新增产品必须改老代码,违反开闭原则。工厂方法模式的思路:不再用一个工厂搞定所有产品,而是定义抽象工厂接口,让每个具体工厂只负责一种产品:public interface NotificationFactory { Notification create(); } public class EmailNotificationFactory implements NotificationFactory { public Notification create() { return new EmailNotification(); } } public class SmsNotificationFactory implements NotificationFactory { public Notification create() { return new SmsNotification(); } }概念工厂方法模式(Factory Method)是一种创建型设计模式,核心思想是将对象的创建延迟到子类。父类定义创建对象的接口(工厂方法),由子类决定实例化哪个具体类。简单工厂 vs 工厂方法:简单工厂通过参数 +if-else集中创建所有产品,适合产品种类少且稳定的场景;工厂方法通过抽象工厂 + 具体工厂将创建职责分散,每个工厂只管一种产品,符合开闭原则——新增产品不改已有代码。简单工厂模式简单工厂不属于 GoF 23 种设计模式,更多的是一种编程习惯。它包含三个角色:

相关新闻

sql 内连接 和in 比较

sql 内连接 和in 比较

NNER JOIN 和 IN 在 SQL 中都能用于关联查询,但它们的适用场景和性能表现有显著差异。下面是详细的对比分析。📊 核心区别对比维度INNER JOININ本质表连接操作,合并两张表集合成员判断操作语法FROM A JOIN B ON A.id B.idWHERE A.id IN (SEL…

2026/10/27 13:21:36 阅读更多 →
51单片机驱动多色LED:从硬件原理到PWM调光实战

51单片机驱动多色LED:从硬件原理到PWM调光实战

1. 项目概述与核心价值上次我们聊了51单片机驱动单色LED的点亮、闪烁和流水灯,算是把最基础的IO口操作给摸透了。但现实中的项目,尤其是那些需要状态指示、氛围营造或者简单信息显示的场合,单色LED往往不够用。一个设备上,你可能需…

2026/11/2 2:16:51 阅读更多 →
SpringBoot微服务架构在高校电子图书馆系统中的应用实践

SpringBoot微服务架构在高校电子图书馆系统中的应用实践

1. 项目背景与核心价值高校图书馆正面临数字化转型的关键时期。传统纸质图书管理存在借阅效率低、资源利用率不均衡、读者行为分析困难等问题。我在参与某985高校智慧校园建设项目时,发现他们2019年的纸质图书平均周转率仅为0.8次/年,而电子资源访问量却…

2026/10/25 3:37:57 阅读更多 →

最新新闻

Electron桌面应用开发实战:从环境搭建到打包发布全流程

Electron桌面应用开发实战:从环境搭建到打包发布全流程

做前端这些年,我大部分时间都在跟浏览器标签页打交道,直到第一次把桌面应用跑起来,才发现原来自己一直被限制在地址栏和刷新按钮围起来的框框里。Electron这个词,最开始是在某段时间频繁出现在同事的讨论里,一个用HTML…

2026/11/2 0:25:10 阅读更多 →
滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

滑盖智能锁T109深度解析:结构原理、安装调试与故障排查

简介:亚太天能T109滑盖智能锁产品说明书是一份PDF格式的官方技术文档,主要面向智能锁安装人员、终端用户及售后维护者,帮助快速掌握产品安装、配置与常见故障处理。全包仅1个PDF文件,大小4.37MB,内容结构清晰&#xff…

2026/11/2 10:46:11 阅读更多 →
PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

PMSM弱磁控制原理与Simulink建模:高速AGV驱动系统设计指南

上个月我在调试一台高速AGV的驱动系统,整车要求空载跑到8m/s,电机转速已经拉到额定点,驱动器的输出电压也顶到了母线电压极限附近。再往上踩速度指令,转速纹丝不动,三相电流反而开始震荡。那会儿我的第一反应就是&…

2026/11/2 10:47:40 阅读更多 →
C++核心知识点:从内存管理到STL的实战指南

C++核心知识点:从内存管理到STL的实战指南

C 这门语言我前前后后折腾了十几年,用它写过嵌入式驱动、做过游戏服务端,也搭过基础组件库。每次看到新人一头扎进"C 核心知识点"这个搜索词,我其实挺感慨的——这门语言的难点从来不是语法多,而是知识点之间的耦合太深…

2026/11/2 1:16:51 阅读更多 →
T109滑盖智能锁怎么装?安装调试与故障排查全攻略

T109滑盖智能锁怎么装?安装调试与故障排查全攻略

简介:亚太天能T109滑盖智能锁产品说明书以PDF格式发布,适合智能锁用户、安装人员与售后维修人员阅读。内容围绕T109系列指纹密码刷卡锁展开,先介绍前面板、后面板、锁体、机械钥匙、电池盒盖等部件名称与功能,再给出完整安装步骤&…

2026/11/2 10:46:31 阅读更多 →
LLM知识降熵:从信息垄断到理解权下放

LLM知识降熵:从信息垄断到理解权下放

你有没有过这种经历:翻开源码注释、论文摘要或者一份专业报告,每个字都认识,连在一起却像天书。想找人聊聊,身边要么没人懂,要么懂的懒得跟你解释。后来我试着把同一段内容丢给一个大语言模型,几秒钟之后&a…

2026/11/2 10:46:26 阅读更多 →

日新闻

周新闻

月新闻