“单一职责原则”的版本间的差异

来自姬鸿昌的知识库
跳到导航 跳到搜索
(建立内容为“理想情况下会是金字塔的结构,任何一个需求都可以被分解为不可再分的粒度的函数实现。 为了不重复造轮子,这些最小…”的新页面)
 
第1行: 第1行:
 +
什么是单一职责原则?
 +
 +
There should never be more than one reason for a class to change.
 +
 +
应该有且仅有一个原因引起类的变更。
 +
 +
 +
 
理想情况下会是金字塔的结构,任何一个需求都可以被分解为不可再分的粒度的函数实现。
 
理想情况下会是金字塔的结构,任何一个需求都可以被分解为不可再分的粒度的函数实现。
  

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

什么是单一职责原则?

There should never be more than one reason for a class to change.

应该有且仅有一个原因引起类的变更。


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

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

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

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