常思一二，设计能力琐思

昨日代码走查，与项目组成员沟通起了“设计能力”的话题，下面为整理的一些沟通记录。

现实情况：

1. 说到设计能力，第一反应就是对设计模式的掌握，两者常常联系在一起。原因就是，刚开始找工作时，为了应对面试，都会熟记设计模式。然而从现实的开发实践来看”对设计模式形态了如指掌”与“代码优雅”两者之间没有什么必然的联系。

2. 认为熟悉画出各种设计模式的UML图（招式），就可以运用好设计模式（内功）。

3. 过度遵循设计模式会使设计出来的代码整体呈现出冗余、死板、鸡肋、臃肿的效果。

4. 现实中所遇到的设计场景往往比设计模式书籍中的案例场景更复杂、更庞大、更多样。

5. 现实中都会存在浮躁、过度设计倾向等因素，因此设计出来的代码逻辑可能过于复杂或者达不到预期，更甚者，设计与实现有时还不是同一个人。

6. 现实中需要多个设计模式混在一起才能实现最佳的设计方式，刻意、生硬地去套用某种设计模式，缺乏灵活运用的能力，往往会使代码显得格格不入。再加上命名的问题，现实情况可能会更糟。

个人理解：

1. 设计能力是考验对设计原则的理解与掌握程度，而设计模式只是所谓的“器”，是对设计原则的落地。

2.  设计原则是基础，只有充分理解设计原则后，才能知晓设计模式背后的思考，以及设计模式中所提到的各种场景为什么需要这样设计。

3.  良好的设计能力应该是潜意识的（潜意识的力量比意识的力量更强大、更隐蔽，很多行为不知不觉受到潜意识的影响）。

4. 设计原则分类：单一职责、里氏替换、接口隔离、迪米特法则、依赖倒置、开闭。开闭原则是最基础的设计原则，其他5个设计原则都是开闭原则的具体形态。也就是说，其他的5个设计原则是指导设计的工具和方法（实现类），而开闭原则才是其抽象（抽象类）。

5. 设计模式分类：创建型，结构型，行为型。这三种类型就可以类比一个对象由内到外的全生命周期，请细品这句话。（这里以对象生命周期的视角去看待对象的变化：创建，使用，消亡。对象有三个不同维度的变化：对象结构的变化、对象规格的变化、对象行为的变化。）

6.  “找到变化，封装变化”这是设计原则底层逻辑，每一种设计模式都是在应对变化这件事。但是学习设计模式起初很少关注什么在变化，如何找到变化，怎么封装变化。更不会关注对象结构的变化、对象规格的变化、对象行为的变化；数据的封装、方法的封装、类型的封装等。

7. 封装与耦合的关系。封装什么东西时，必然将使其耦合变松。隐藏实现（即封装它们）有助于松耦合。万物皆对象，把所有事物抽象与封装成对象，对象对自己行为所负的责任越多，控制程序需要负的责任就越少。封装使对象内部行为的变化对其他对象变得透明了，封装有助于防止不良副作用。

8. 设计能力对系统掌控力影响很大，能够通过代码层面的设计以及规范来保证系统架构最小程度的受到人员水平、人员协作、需求复杂度等因素的影响，保障系统可靠性、灵活性、可维护、可扩展、可复用、可演进，进而避免人员无效率加班内卷。