架构设计模式七大原则

一、为什么你必须先懂「原则」,再谈「模式」?

很多小伙伴一上来就背 23 种设计模式,结果越学越晕。

其实 所有设计模式都围着七大原则转------把它们吃透,模式只是信手拈来的招式。

二、七大原则,一条一条拆给你看!

① 单一职责原则(SRP)

一句话:一个类只做一件事。

颜色加粗重点 :如果类名里出现 "And"、"Or",八成已经违背 SRP。

修改前(反面教材)

复制代码
class UserServiceAndReport {
    void register() { /* 注册逻辑 */ }
    void exportPDF() { /* 导出报表逻辑 */ }
}

修改后(符合 SRP)

复制代码
// 只负责用户注册
class UserService {
    void register(User user) { /* 注册逻辑 */ }
}

// 只负责报表导出
class ReportService {
    void exportPDF(User user) { /* 导出报表逻辑 */ }
}

注解:

  1. 把 注册 和 报表 拆到两个类,职责单一。

  2. 修改注册逻辑时,不会误伤报表功能,风险降低。

  3. 单元测试粒度更细,定位 bug 事半功倍。

② 开闭原则(OCP)

一句话:对扩展开放,对修改关闭。

颜色加粗重点 :新增功能靠 "加代码" ,而不是 "改旧代码"。

场景:订单折扣系统
复制代码
// 抽象策略
interface DiscountStrategy {
    BigDecimal apply(BigDecimal price);
}

// 新需求:双十一折扣
class DoubleElevenDiscount implements DiscountStrategy {
    public BigDecimal apply(BigDecimal price) {
        return price.multiply(new BigDecimal("0.8"));
    }
}

// 使用方
class OrderService {
    BigDecimal pay(BigDecimal price, DiscountStrategy strategy) {
        return strategy.apply(price);
    }
}

注解:

  1. 新增 DoubleElevenDiscount 时,完全不动 OrderService。

  2. 所有折扣策略实现同一接口,扩展点清晰。

  3. 遵循 OCP,减少回归测试成本。

③ 里氏替换原则(LSP)

一句话:子类必须能无缝替换父类。

颜色加粗重点:别把正方形硬塞进长方形的模子。

复制代码
// 定义接口
interface Shape {
    int area();
}

// 长方形
class Rectangle implements Shape {
    int width, height;
    public int area() { return width * height; }
}

// 正方形(保证 LSP)
class Square implements Shape {
    int side;
    public int area() { return side * side; }
}

注解:

  1. 正方形 不继承长方形,避免 setWidth 时破坏高度。

  2. 只实现 Shape 接口,任何 Shape 都能被统一调用。

  3. 满足 LSP,消除运行时类型检查的尴尬。

④ 接口隔离原则(ISP)

一句话:客户端不依赖它用不到的方法。

颜色加粗重点:胖接口 = 胖 bug 源。

拆分前
复制代码
interface Machine {
    void print();
    void scan();
    void fax();
}

拆分后

复制代码
interface Printer { void print(); }
interface Scanner { void scan(); }
interface Fax { void fax(); }

class AllInOne implements Printer, Scanner, Fax {
    /* 真正实现 */
}

注解:

  1. 老式打印机只实现 Printer,不必空实现 scan/fax。

  2. 接口粒度变小,降低实现类的心智负担。

  3. 遵循 ISP,提高代码可维护性。

⑤ 依赖倒置原则(DIP)

一句话:高层模块不依赖低层,二者都依赖抽象。

颜色加粗重点:面向接口编程,而不是面向实现。

示例:通知系统

复制代码
// 抽象
interface Notifier {
    void send(String msg);
}

// 低层实现
class EmailNotifier implements Notifier {
    public void send(String msg) { /* 发邮件 */ }
}

// 高层业务
class OrderService {
    private final Notifier notifier; // 依赖抽象
    OrderService(Notifier n) { this.notifier = n; }
    void finishOrder() { notifier.send("订单完成"); }
}

注解:

  1. OrderService 只认 Notifier,不关心是邮件还是短信。

  2. 想换短信通知?只需新增 SmsNotifier,零修改高层。

  3. 完美体现 DIP,系统松耦合。

⑥ 迪米特法则(LoD)

一句话:只和直接朋友说话。

颜色加粗重点 :链式调用 a.getB().getC().do() 是大忌。

反例

复制代码
class Wallet {
    public Money money;
}
class Person {
    public Wallet wallet;
}
// 客户端
person.getWallet().money.reduce(100);

正例

复制代码
class Person {
    private Wallet wallet;
    public void pay(int amount) {
        wallet.pay(amount);
    }
}
// 客户端
person.pay(100);

注解:

  1. 客户端只认识 Person,完全不知道 Wallet 的存在。

  2. 降低耦合,类内部变化不影响外部调用。

  3. 遵循 LoD,代码更易读、更安全。

⑦ 合成复用原则(CRP)

一句话:优先组合,而非继承。

颜色加粗重点:继承是"亲儿子",组合是"干儿子",后者更灵活。

继承 VS 组合

复制代码
// 继承 ------ 紧耦合
class Bird extends Flyable { }

// 组合 ------ 松耦合
class Bird {
    private FlyBehavior flyBehavior; // 组合
    void fly() { flyBehavior.fly(); }
}

注解:

  1. 组合让 Bird 在运行时动态切换飞行策略。

  2. 不会陷入"类爆炸"的继承泥潭。

  3. 体现 CRP,系统扩展性 max。

总结

单一职责 -> 拆!

开闭原则 -> 加!

里氏替换 -> 换!

接口隔离 -> 瘦!

依赖倒置 -> 抽象!

迪米特 -> 少说话!

合成复用 -> 组合!

背口诀:"拆加换瘦抽象少说话,组合优先"

相关推荐
Pin_Qing12 分钟前
账单没超,请求先被拒了
大数据·开发语言·人工智能
2601_9628857214 分钟前
如何用 Python 计算 VaR 和 CVaR(在险价值)?
开发语言·python
杨杨杨大侠19 分钟前
DeepSeek Harness:连 Agent Loop 都能替换的插件架构
java·人工智能·agent
SL_staff19 分钟前
私有化低代码运维三重雷区:JVS开源栈中的Kafka/ES/RabbitMQ治理实践
java·低代码·全栈
yuniko-n20 分钟前
【算法】约瑟夫环问题
java·算法
郝亚军29 分钟前
manifest 中 `sha256` 与 `signValue` 的作用
java·开发语言·数据结构
譕痕44 分钟前
stripe 实例
java·开发语言·stripe·checksession
墨子夕1 小时前
设计模式——Java × Python 双语言精讲 · 23 个经典模式 + 现代演进(前言篇)
java·开发语言·设计模式
骇客野人1 小时前
Linux 全套实操方案(含目录详解、文件传输、日志、文件规范、环境变量、Java 应用部署运维)
java·linux·运维
_菜鸟果果1 小时前
高德地图 JS API 2.0 在国产 Linux/ARM 电脑上渲染失败 的排查与解决
linux·开发语言·javascript