单例模式确保一个类只有一个实例，适用于资源管理、配置中心等场景，推荐使用静态内部类实现；工厂模式解耦对象创建过程，适用于根据不同参数动态创建子类对象的场景，如支付系统；观察者模式用于一对多依赖关系，实现事件驱动机制，如订单创建后触发多个操作；模板方法模式封装算法骨架，适用于步骤固定但部分实现变化的场景，如导出报表。这四种模式在实际项目中常组合使用，提升代码可维护性和扩展性。
在Java开发中，设计模式的合理使用可以提升代码的可维护性和扩展性。很多人学过设计模式，但实际项目里怎么用，什么时候用却常常拿不准。这篇文章就结合几个常见的设计模式，讲讲它们在真实项目中的典型应用场景和写法。
单例模式：确保一个类只有一个实例
单例模式是用得最多的模式之一，特别是在管理资源、配置中心或者工具类中非常常见。比如数据库连接池、日志工厂等场景下，我们通常希望全局只有一份实例，避免重复创建带来的开销。
实现方式上，最推荐使用静态内部类的方式：
立即学习“Java免费学习笔记（深入）”；
public class DBConnectionPool {
private DBConnectionPool() {}
private static class Holder {
private static final DBConnectionPool INSTANCE = new DBConnectionPool();
}
public static DBConnectionPool getInstance() {
return Holder.INSTANCE;
}
}这种方式既保证了线程安全，又实现了懒加载。在Spring框架中，很多Bean默认就是单例作用域，背后也是类似的机制。
工厂模式：解耦对象的创建过程
工厂模式常用于需要根据参数动态创建不同子类对象的场景。比如支付系统中，根据用户选择的不同支付方式（支付宝、微信、银联）来创建对应的支付处理器。
举个例子，定义一个接口：
public interface PaymentHandler {
void pay(double amount);
}然后有多个实现类，如 AlipayHandler、WechatPayHandler 等。这时候可以通过一个工厂类来统一创建：
public class PaymentFactory {
public static PaymentHandler getHandler(String type) {
switch (type) {
case "alipay": return new AlipayHandler();
case "wechat": return new WechatPayHandler();
default: throw new IllegalArgumentException("Unsupported payment type");
}
}
}这样调用方只需要传入类型，不需要关心具体实现类，也方便后续扩展新的支付方式。
观察者模式：实现事件驱动机制
观察者模式适用于一对多的依赖关系，当被观察对象状态变化时，通知所有观察者进行响应。在Java中，这个模式广泛应用于事件监听机制，比如GUI界面按钮点击、消息队列的消费者订阅等。
举个简单的业务例子：订单下单后要发短信、发邮件、更新库存等多个操作。
我们可以定义一个事件监听器接口：
public interface OrderListener {
void onOrderCreated(OrderEvent event);
}然后不同的处理逻辑实现该接口，并注册到订单服务中。订单创建时触发事件广播：
public class OrderService {
private List<OrderListener> listeners = new ArrayList<>();
public void addListener(OrderListener listener) {
listeners.add(listener);
}
public void createOrder(Order order) {
// 创建订单逻辑...
OrderEvent event = new OrderEvent(order);
for (OrderListener listener : listeners) {
listener.onOrderCreated(event);
}
}
}这种结构让订单核心逻辑与后续动作解耦，新增功能只需添加监听器即可，无需修改主流程。
模板方法模式：封装算法骨架
模板方法模式适合那些步骤固定但部分步骤实现可能变化的场景。比如导出报表，流程可能是：准备数据 → 生成文件内容 → 写入文件 → 发送邮件，其中“生成文件内容”这一步会因文件格式（Excel、PDF）而不同。
定义一个抽象类：
public abstract class ReportExporter {
public final void export() {
prepareData();
String content = generateContent(); // 子类实现
writeFile(content);
sendEmail();
}
private void prepareData() { /* 公共逻辑 */ }
protected abstract String generateContent();
private void writeFile(String content) { /* 写入文件逻辑 */ }
private void sendEmail() { /* 发送邮件逻辑 */ }
}然后子类只需关注内容生成部分：
public class ExcelExporter extends ReportExporter {
@Override
protected String generateContent() {
return "Excel格式的数据内容";
}
}这样整体流程统一控制，局部灵活扩展，非常适合构建标准化流程的模块。
这些设计模式在实际项目中不是孤立存在的，很多时候会组合使用。比如Spring框架中，IoC容器本身大量使用了工厂模式和代理模式；事件监听体系则是基于观察者模式；AOP底层则涉及到了装饰器模式和动态代理。
掌握它们的关键在于理解适用场景和解决的问题，而不是死记硬背。只要在合适的上下文中使用，就能真正提升代码质量。
基本上就这些，不复杂但容易忽略的是如何在真实业务中找到合适的位置去应用它们。
