写代码无非追求两个目标,第一是满足需求,第二是面对需求变化时好维护。
好维护的首要前提是我们能够理解代码,其次是代码好修改。
代码好修改的核心是良好的代码组织,良好的代码组织意味着高内聚低耦合,没有重复。
设计模式主要就是用来达到上述目标的。
学习设计模式时,估计有的人仅仅是记住了每个模式的形,而没有考虑每个模式是用来解决什么问题的,且更加会忽略只有代码需要变化时才会带来这些问题这个事实。
正确的学习思路,应该是首先思考这个模式是用来解决遇到什么变化时,如何通过达到高内聚低耦合满足需求,然后思考如果不采用模式会出现啥问题。
而在写代码时,首先得考虑可能会发生哪些变化,概率有多大,如果已经明确一个变化不会出现,何必花费心思去搞什么模式,采用简单直接的方法解决为啥不可。
高内聚低耦合,没有重复不仅仅是针对类,对文件,包,程序一样都行得通。
对于高内聚(大家都内聚了自然互相之间低耦合)的理解尤为重要,高内聚有时也叫做单一职责原则(一个关注点,只要觉得是一个关注点就应该独立起来)。
目前为止,我了解到的一些设计原则之类的,都满足上面的理解。
对可见性的封装,可以保持低耦合。
变化自然是关注点,不是关注点自然不会变化。对一个变化点的进行封装,也就是对一个关注点的进行封装,自然就是高内聚的。
继承对应的是没有重复。
多态也是间接为了高内聚,比如经常举得Shape的例子,drawAll关注的是画图形,而不关注具体是什么图形,为了把不关注点搞出去(不搞出去就不是高内聚),就得利用多态特性。
抽象是为了低耦合。
依赖倒置原则把变化的部分抛出去,且让变化依赖于它提供的抽象,自然是为了它与变化的低耦合。
工厂模式是把对象的创建过程抛出去,作为单独的一个关注点
不同层次的关注点大小不一样,比如PL关注的是项目,组员关注的是项目中的一个模块,如果PL直接关注了多个模块,那么他就不是内聚的,如果PL是通过指示组员间接去关注若干模块,他不会直接写代码,他就是内聚的。
如果你能只保持一个关注点,那么你做起来就不会太复杂,至少没有其他因素的干扰。
如果你能只保持一个关注点,那么你稳定的可能更大。
发现你关注点中的子关注点,通过抽象分离出去,保持自己真正的关注点。