开启设计模式之旅（一）

       平时学习的时候看到过很多比如Java程序设计，C程序设计，C++程序设计，C#程序设计，Objective-c程序设计等等的书籍，但发现里面也没怎么去讲程序的设计，顶多也就是讲讲语法什么的，以至于一开始写程序的时候从来没有考虑过程序该如何设计，程序该如何应对未来的发展需要，程序该如何像构件一样拿来就用。每次都是一个项目一套程序，换做其它类似的项目，类类似的功能模块时也只是copy而已，程序再写的时间长一点，可能会把一个项目中公共的代码抽离出来使用。但这样在做项目的时候工作量还是大的不得了，由于开始抱怨产品部的设计有问题，抱怨所用技术为什么就不能为程序员提供更方便更省力气的库什么的。偶然间听一以设计模式这个概念，说程序是可以设计成像构件这样的东西，可以大大提高程序的扩展性，复用性。于是开始找这方面的资料。我找到两本还不错的书《设计模式之禅》，《研磨设计模式》。就从这两本书着手开始我的设计模式之旅吧。

        学设计模式要问自己一些问题，带着问题去学习可能针对性更强一些，学习效果会更好一些。

        问题：（1）业务分析如此细致，架构设计如此健壮，可靠和稳定，但为何仍然无法适应业务发展的需要，而且生命周期只有短短几年？

                    （2）为何团队协作了多年却始终无法沉淀出可复用的组件或构件？依赖和解耦的标准是什么？如何才能做到既不相互“刺伤”，又能相互“协作”？

                    （3）架构设计时，如何才能实现高可扩展性和易维护性？如何避免维护成本大于开发成本的悲惨现状？

                    （4）交易型的系统如何实现高性能，高可靠性的建设目标？

                    （5）架构设计时，如果遇到这样的情况：“有一个访问者，多个响应者，同时要求二者之间解耦，以便响应者可以动态地扩展，这该如何处理？

                   ”（6）如果遇到这样的场景：“多个对象依赖于一个对象，那如果这一个对象的状态发生了改变，所有依赖于他的其它多个对象都应该得到通知，并且要求对象间是松耦   合的”，这该如果设计程序？

        做事情都的有原则，学设计模式我的先学习6大设计原则了，我按书上的顺序一个一个原则的学习，但是看我的是一头雾水。

         第一大原则是：

         单一职责原则（Single Resposibility Principle 简称 SRP）：单一的职责。作者说这个设计原则是倍受争议的，想想也是，在理论上我们在设计程序的时候，职责分明，而且单一职责当然会结构清晰，这样的话最起码在代码的阅读上和代码的维护上会很容易。这就好像中国人，吃饭用筷子，喝汤调羹。理论上是这样的，便在实际中都是这样的吗？小孩子吃饭不用筷子，他们可能只用调羹。作者也说了，理论上我们是要遵守单一职责原则 ，但是实际开发中可能因各种原因被破坏掉。

          程序设计为什有一条这样的原则，看了单一原则的好处我明白了，但好处我也只从字面上觉的好，因为如果没有实际的应用，是不能真正感觉到它的好处的

          单一职责原则的好处如下：

          （1）类的复杂性降低，实现什么职责都有清晰明确的定义；

          （2）可读性提高；

          （3）可维护性提高；

          （4）变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，

            对其他的接口无影响，这对系统的扩展性，维护性都有非常大的帮助。

            单一职责原则是好，但是单一职责原则中职责是最难划分的，比如一个职责我们定义一个接口，但问题是“职责”没有一个量化的标准，

一个类到底要负责那些职责，这些职责该怎么细化？细化后是否都要有一个接口或类？这些都不能只从理论上来考虑，得和所做的项目实际情况相结合

来考虑。所以虽然单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类的设计是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

           说到如何在项目中使用单一职责原则，作者给了一些建议：

          对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了，生搬硬套单一职责原则最终会导致类的剧增，这样会给维护带来非常多的麻烦。而且过分细分类的职责也会人为地增加系统的复杂性。想想也是，比如本来一个类可以实现的行为硬要拆成两个类，然后再使用聚合或组合的方式耦合在一起，人为制造了系统的复杂性。得不尝失啊。俗话说的好，原则是死的，人是活的，没错！理论永远要和实际相结合才是王道！

          单一职责原则适用于接口，类，同时也适用于方法。一个方法尽可能做一件事情，这个好像看是懂了，平时在开发中有意无意的也在这么用。原来这些高深的东西自己一直在用却不知道它。正所谓道不远人。有些看似高深的东西，其实就在我们身边，只是我们没有发现而已。

        对于单一职责原则，接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。