设计模式学习心得----开篇

做了几年的开发工作，还停留在开发工程师的阶段，想着不能一直这样下去，觉得要为自己以后做打算了，开发常规两条路：项目管理，架构师，我选择架构师。之 所以这样选，这是保守的一个选择，用格力的广告“掌握核心科技”，只有掌握了核心技术，核心业务，才能占据主导角色。当然要成为一个合格的架构师，需要学 习的，掌握的东西要非常多，非常全面，也有很多条件，但这是我选架构师的一个最重要条件。既然已经决定了，就要学习自己欠缺的。设计模式就是之一，于是有 了这系列文章，记录学习过程中一些心得和总结。

　　[b]一：为什么要用设计模式[/b]

在我进入这家电商前，因为做得都是些小项目，设计模式基本用不上。到现在公司后，还是一样，不是说设计模式没用武之地，而是开发任务重，在一次次修改功能， 增加功能过程中，虽然知道如果这里封装好点，就不用费力维护了。但为了按时完成任务，谁管你维护难不难。结果可想而知。

就是这样设计模式为了系统的可维护性，可扩展，可复用。

　　

　　二：重新认识面向对象

从宏观层看：面向对象的构建方式更实用软件的变化，把变化带来的影响降到最低。

从微观层看：面向对象更强调对象的责任，新的变化不会影响原对象代码的变动。

对象是什么：1，拥有某种责任的抽象。2，可以被其他对象使用的公共接口。3，拥有属性和方法。

　　三：设计原则

1：针对接口编程，而不是实现

　　客户（调用方或客户程序）无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。

2：优先使用对象组合，而不是继承

　　继承在某种程度上破坏了封装性，子类和父类的耦合度高；而对象组合只要求被组合的对象具有良好定义的借口，耦合度低。

3：封装变化点

　　使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另外一侧产生不良的影响，甚至不需要修改另一侧，从而实现层次间的松耦合。

4：模式从重构得来

　　设计模式的使用不宜先入为主，一开始就使用设计模式是对设计模式最大的误用。没有一步到位的设计，设计模式不是算法，直接拿来就可以用。敏捷软件开发实践提倡的“refactoring to patterns”(重构与模式)是目前普遍公认的最好的使用设计模式的方法。

　　[b]四：更具体的设计原则[/b]

1：单一职责(srp)

　　一个类应该仅有一个引起他变化的原因。

　　----

2：开放封闭原则

　　类模块应该是可以扩展的，但是不可以修改（对扩展开放，对修改封闭）。

3：里氏替换原则

　　子类必须能够替换他的父类。

4：依赖倒置原则

　　高层模块不应该依赖低层模块，二者都应该依赖于抽象。

　　抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

5：接口隔离原则

　　不应该强迫客户程序依赖于他们不用的方法。

　　

　　[b]五：模式的分类[/b]

1：创建型，负责对象的创建

2：结构性，处理类与对象的组合。

3：行为型，类与对象交互中的职责分配。