做了几年的开发工作，还停留在开发工程师的阶段，想着不能一直这样下去，觉得要为自己以后做打算了，开发常规两条路：项目管理，架构师，我选择架构师。之 所以这样选，这是保守的一个选择，用格力的广告“掌握核心科技”，只有掌握了核心技术，核心业务，才能占据主导角色。当然要成为一个合格的架构师，需要学 习的，掌握的东西要非常多，非常全面，也有很多条件，但这是我选架构师的一个最重要条件。既然已经决定了，就要学习自己欠缺的。设计模式就是之一，于是有 了这系列文章，记录学习过程中一些心得和总结。
一：为什么要用设计模式
在我进入这家电商前，因为做得都是些小项目，设计模式基本用不上。到现在公司后，还是一样，不是说设计模式没用武之地，而是开发任务重，在一次次修改功能， 增加功能过程中，虽然知道如果这里封装好点，就不用费力维护了。但为了按时完成任务，谁管你维护难不难。结果可想而知。
就是这样设计模式为了系统的可维护性，可扩展，可复用。
二：重新认识面向对象
从宏观层看：面向对象的构建方式更实用软件的变化，把变化带来的影响降到最低。
从微观层看：面向对象更强调对象的责任，新的变化不会影响原对象代码的变动。
对象是什么：1，拥有某种责任的抽象。2，可以被其他对象使用的公共接口。3，拥有属性和方法。
三：设计原则
1：针对接口编程，而不是实现
客户（调用方或客户程序）无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望的接口。
2：优先使用对象组合，而不是继承
继承在某种程度上破坏了封装性，子类和父类的耦合度高；而对象组合只要求被组合的对象具有良好定义的借口，耦合度低。
3：封装变化点
使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另外一侧产生不良的影响，甚至不需要修改另一侧，从而实现层次间的松耦合。
4：模式从重构得来
设计模式的使用不宜先入为主，一开始就使用设计模式是对设计模式最大的误用。没有一步到位的设计，设计模式不是算法，直接拿来就可以用。敏捷软件开发实践提倡的“refactoring to patterns”(重构与模式)是目前普遍公认的最好的使用设计模式的方法。
四：更具体的设计原则
1：单一职责(srp)
一个类应该仅有一个引起他变化的原因。
----
2：开放封闭原则
类模块应该是可以扩展的，但是不可以修改（对扩展开放，对修改封闭）。
3：里氏替换原则
子类必须能够替换他的父类。
4：依赖倒置原则
高层模块不应该依赖低层模块，二者都应该依赖于抽象。
抽象不应该依赖于实现细节，实现细节应该依赖于抽象。
5：接口隔离原则
不应该强迫客户程序依赖于他们不用的方法。
五：模式的分类
1：创建型，负责对象的创建
2：结构性，处理类与对象的组合。
3：行为型，类与对象交互中的职责分配。