“设计模式”的版本间的差异

来自姬鸿昌的知识库
跳到导航 跳到搜索
第2行: 第2行:
  
 
==== 单一职责原则 ====
 
==== 单一职责原则 ====
 +
 +
 +
理想情况下会是金字塔的结构,任何一个需求都可以被分解为不可再分的粒度的函数实现。
 +
 +
为了不重复造轮子,这些最小粒度的函数又可以和同粒度的函数结合产生一个新的函数供上层调用,这样一层一层的构成会是耦合程度最理想、应用最灵活的代码。
 +
 +
但实际情况是:如果真的严格遵守、实践 SRP,一定会得到一个类爆炸的结果,实际应用中因为底层函数太多,开发者不会记得住,最后还是难以避免冗余的函数实现出现。
 +
 +
所以实践中是:接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。
  
 
==== 里氏替换原则 ====
 
==== 里氏替换原则 ====

2022年8月14日 (日) 07:03的版本

设计原则

单一职责原则

理想情况下会是金字塔的结构,任何一个需求都可以被分解为不可再分的粒度的函数实现。

为了不重复造轮子,这些最小粒度的函数又可以和同粒度的函数结合产生一个新的函数供上层调用,这样一层一层的构成会是耦合程度最理想、应用最灵活的代码。

但实际情况是:如果真的严格遵守、实践 SRP,一定会得到一个类爆炸的结果,实际应用中因为底层函数太多,开发者不会记得住,最后还是难以避免冗余的函数实现出现。

所以实践中是:接口一定要做到单一职责,类的设计尽量做到只有一个原因引起变化。

里氏替换原则

依赖倒置原则

接口隔离原则

迪米特法则

开闭原则

设计模式

单例模式

工厂方法模式

抽象工厂模式

模板方法模式

建造者模式

代理模式

原型模式

中介者模式

命令模式

责任链模式

装饰模式

策略模式

适配器模式

迭代器模式

组合模式

观察者模式

门面模式

备忘录模式

访问者模式

状态模式

解释器模式

享元模式

桥梁模式