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