说点题外话02｜模式并不是解决方案

貌似开了点窍，总结一下，有把锤子哪里都是钉子，有了一套解决方案什么问题都能套得上，但不是每个问题都是同一个问题 由具体问题抽象出解决方案，再在解决方案指导下给出处理具体问题具体路径 问题N：N模式 转化为 问题N：1 解决方案 1：N具体模式 这是N:N的关系，必然从一边是推导不出另一边的 文中的每个问题抽象出是要可扩展，解决方案是面向接口编程，但每个问题都不同，所以具体行为也不同，策略模式是应对行为，状态模式是应对状态 解决方案是一个，可问题却各自具象，魔鬼在细节 能力供应商模式也是同样的，从表面看是接口定义在domain,实现在其它地方，保证domain的稳定，形式上跟很多相似，ACL、整洁架构，也就是解决方案相似，但其实解决的具体问题不同，所以不能说能力供应商就是ACL 很多时候程序员不是在编写代码，而是在摸索业务领域知识；也就是从当前的代码去推测当时在解决什么问题，再重新定义问题，进行重构，这是因为知识没有有效传承，或者没有达到代码即模型

夜不能寐，尝试答一下… 1 关联对象，通过将集合逻辑封装到关联对象中的方式解决聚合时性能和逻辑封装之间的矛盾。 2 角色对象，通过将实体在不同上下文中的逻辑封装在不同的角色对象中，解决上下文过载问题。 3 上下文对象，通过显式的对上下文进行建模，将跨域业务逻辑和上下文依赖封装到领域对象中，进一步解决上下文过载问题。 4 能力供应商，通过从基础设施层提取具备业务含义的能力接口纳入到领域层，消除基础设施层，将其转变为能力供应商，参与各层逻辑，解决传统分层下，领域层和基础设施层之间“不正当”的依赖关系破坏了领域层的稳定性的问题。

说的非常对，but现在很多的实际场景就是根据代码来推测当时要解决的问题，也确实容易走偏（在熟悉业务之后，发现当时可能偏了）

2024年01月17日09:04:28 所以我理解应该是定义清楚问题，再去找解决方案。同时我们学习设计模式的时候，也应该先清楚这个模式解决了什么问题，而不是直接上去学习模式是什么。

最难的还是如何把问题定义好。

设计模式不是设计出来的

换句话说，如果看代码知道了模式，那就可以确定其需要解决的问题和具体的解决方案。

策略模式是应对行为，状态模式是应对状态

深呼吸啊😮‍💨