随着AI编程使用的普遍， 对开发人员的设计能力的要求会越来越高，用AI设计出高复用，低耦合，向后兼容，比较健壮的代码， 是有必要好好研究设计模式的。

首先列下 设计模式的七大原则简介：

原则名称	核心定义（官方）
单一职责原则	一个类应该只有一个引起它变化的原因。
开闭原则	软件实体（类、模块、函数等）应该对扩展开放，对修改关闭。
里氏替换原则	所有引用基类（父类）的地方必须能透明地使用其子类的对象。
接口隔离原则	客户端不应该被迫依赖于它不使用的接口。
依赖倒置原则	1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象。 2. 抽象不应该依赖细节，细节应该依赖抽象。
迪米特法则	一个对象应该对其他对象有最少的了解。只与直接的朋友通信。
合成复用原则	尽量使用对象组合（Composition）或聚合（Aggregation），而不是继承关系达到复用的目的。

我觉得这种名字，有的是根据人名有的是依据特点命名，乱的很，也记不住，没有一个结构化的描述，也不容易整合其思想。再加上令人费解的官方核心定义，似乎是和名字八竿子打不着的关系，感觉这个玩意在整个互联网里被加上了防自学手段，有些无语。

故我在23种设计模式上凝练出来了一个拟人化的框架系统，总结出了一个不用费劲就能理解，能记得很牢靠的方式。

设计模式的几大原则无非就是描述了一个类与其所有关联类的边界， 以及描述了它的行为应当遵循的原则。如果这个类是一个“人”的话，假设你在写代码的时候，创造的这个类就是你自己本人，下文用“我”来描述。那么无外乎就是以下的关系

• 我及我父辈，你先天有的能力出自你的父辈，遗传来的
• 我及我的平辈，朋友，合作伙伴。这些关系整合好，在你继承父辈的能力下，你能完成更加完善的功能，产生价值。
• 我作为服务者，服务于哪些客户 (我为谁创造价值，我们之间应当遵循什么原则)
• 谁服务于我(谁会为我创造价值，我应当怎么用这个服务者呢)

这几乎抽象出了一个人存在于社会的所有关系。其实也映照了代码世界里一个类应当处理的所有关系，七大设计原则本质上是对这种关系的约束，以及行为的约束而已。

所以我的版本里对这七大原则的归类为

关系	原则
我对我家人， 朋友，助手之间的原则	里氏替换原则
	合成复用原则
	迪米特法则
我作为服务提供者遵循的原则	单一职责原则
	依赖倒置原则
	开闭原则
我作为被服务者应当遵循的原则	接口隔离

下文为对这些关系的原则讲解，大部分是画图展示的：

我对我家人和助手的原则

里氏替换(对于我们的父辈，他们能干的活我和我的同辈也能干，可完全适配)

合成复用原则(我与我合作伙伴的关系，应当尽量是聚合的关系，其次是组合，其次才是继承)

迪米特法则(致伙伴:不要不经过我同意，别动我东西。同时我也不会不经你同意，动你的东西。 致自己： 自己的东西最好放在柜子里，别摆在台子上让人家动)

迪米特法则的原本解释是：

• 一个类，对于其他的类知道的越少越好。
• 只与直接的朋友通信。

• • 朋友指的是： 聚合，组合，依赖， 关联关系
  • 直接的朋友：成员变量，方法参数， 方法返回值中的类。

很难记， 就这种东西不理解到本质，看几遍忘几遍。我不认为这是一个好的解释。迪米特法则的本质就是知道的越少越好！

我作为服务者的原则

单一职责(对于我服务的对象， 不应因他们的变化，而频繁改动而影响我的服务质量)

依赖倒置原则(我的服务内容再怎么增删查改，也不要影响我服务的客户强迫人家改动代码来适应， 同时我服务的客户如果有新的需求加了接口，我也可以选择性实现)

开闭原则(当客户有新的需求时，尽量不要动之前的代码，而是新增接口。免得改错了，之前的客户会影响到)

我作为客户时的原则

接口隔离(我作为被服务者的时候，尽量找专业的服务员，而不是啥都能做的服务员)

这个是将心比心， 与单一职责原则，身份互换， 就是被服务者也尽量不要瞎用啥都能做的服务员。

总结图