@telaviv 商业公司如此，你可以不用它的产品，用钱包投票即可

@fkdog 复读机？ 也不算吧，光是理解问题域，发现问题域中 难以变化的部分 将其剥离出来形成一种机制 与易变化的部分隔离 就要对领域知识有充足的了解，而并非对代码技术有多么深层次的理解。

理解软件工程以及代码架构，关键是你要理解一点，

那就是不管 SOLID 原则以及设计模式的运用都是在做同一件事情，将易变的部分与不易变的部分隔离开来，更抽象的说法就是提供一套机制将策略与机制分离开来。

一般来说机制是难以变化的，而策略经常变化，一个软件，框架可以看成一种机制，因为写业务大多只是使用框架提供的功能，而并非去对框架进行修改，也就是说框架是不易变的，而业务逻辑是易变的，在这里框架是一种机制，业务代码是一种策略，例如 mybaits 框架，你编写 SQL xml 这就是一种策略，而 mybatis 框架本身就是一套机制。

做到这一点首先要对目标域的问题进行分解，发现难以变化的部分以及容易变化的部分，
例如 Spring 框架，通过 XML 加载 bean 定义的 或者 通过类扫描 加载 Bean 定义 又或者你要自定义一种其它的方式来加载 bean 定义，总儿言之加载 Bean 定义的方式是多种变化的，但是对 bean 本身来说，bean 需要解决的领域问题是确定的，是不会变化的，所以抽象出来一个 BeanDefination 用于初始化 Bean ，这样 BeanDefination 作为一种初始化 bean 数据结构的机制是不易变的，而具体加载生成 BeanDefination 的策略是易变的。

类似的设计思想还有很多，例如 BeanFactoryPostProcessor BeanPostProcessor 也是这样一种思想，框架本身提供了一种回调的机制，至于你如何客制化 BeanDefination 或者 客制化 Bean 的 instance 则是一种具体的策略。

像 sort 方法 排序算法本身是一种机制，至于如何比对两个对象的大小则是一种具体的策略。

总而言之，在代码层面上，你要时刻去思考，你的代码如果要复用，那么被复用的代码应该提供一种什么样的机制，让具体的策略去使用去组合起来方便，而不至于需要修改你原本的，至于具体的设计模式 反倒并没有那么重要，

没有这个必要，微信搞得这么复杂，不还是有人去研究破解微信的协议，想啥呢，老哥，只要有利益驱动，自然有人去研究你的协议，技术手段只是防止对方低成本破解罢了。

加我，我的微信号最屌 iwannafuckwechat

@Cu635 提前打 没卵用，你一打，人家就加速 本来都慢悠悠的，你一打转向灯 他就急了 要加速