由学习设计模式想到的（精华2）

写代码无非追求两个目标，第一是满足需求，第二是面对需求变化时好维护。

好维护的首要前提是我们能够理解代码，其次是代码好修改。

代码好修改的核心是良好的代码组织，良好的代码组织意味着高内聚低耦合，没有重复。

设计模式主要就是用来达到上述目标的。

学习设计模式时，估计有的人仅仅是记住了每个模式的形，而没有考虑每个模式是用来解决什么问题的，且更加会忽略只有代码需要变化时才会带来这些问题这个事实。

正确的学习思路，应该是首先思考这个模式是用来解决遇到什么变化时，如何通过达到高内聚低耦合满足需求，然后思考如果不采用模式会出现啥问题。

而在写代码时，首先得考虑可能会发生哪些变化，概率有多大，如果已经明确一个变化不会出现，何必花费心思去搞什么模式，采用简单直接的方法解决为啥不可。

高内聚低耦合，没有重复不仅仅是针对类，对文件，包，程序一样都行得通。

对于高内聚（大家都内聚了自然互相之间低耦合）的理解尤为重要，高内聚有时也叫做单一职责原则（一个关注点，只要觉得是一个关注点就应该独立起来）。

目前为止，我了解到的一些设计原则之类的，都满足上面的理解。

对可见性的封装，可以保持低耦合。

变化自然是关注点，不是关注点自然不会变化。对一个变化点的进行封装，也就是对一个关注点的进行封装，自然就是高内聚的。

继承对应的是没有重复。

多态也是间接为了高内聚，比如经常举得Shape的例子，drawAll关注的是画图形，而不关注具体是什么图形，为了把不关注点搞出去（不搞出去就不是高内聚），就得利用多态特性。

抽象是为了低耦合。

依赖倒置原则把变化的部分抛出去，且让变化依赖于它提供的抽象，自然是为了它与变化的低耦合。

工厂模式是把对象的创建过程抛出去，作为单独的一个关注点

不同层次的关注点大小不一样，比如PL关注的是项目，组员关注的是项目中的一个模块，如果PL直接关注了多个模块，那么他就不是内聚的，如果PL是通过指示组员间接去关注若干模块，他不会直接写代码，他就是内聚的。

如果你能只保持一个关注点，那么你做起来就不会太复杂，至少没有其他因素的干扰。

如果你能只保持一个关注点，那么你稳定的可能更大。

发现你关注点中的子关注点，通过抽象分离出去，保持自己真正的关注点。