设计，为了更好的应对变化

什么是设计模式？

 1.是解决某些问题的办法
 2.不是凭空想象的，是经验的积累和总结

不可预测的变化。

   产品的上线只是第一步，维护和拓展才是我们花很长时间去做的。

  1.当前期设计不合理，后期维护出现重大问题如何处理？立即修复、接着挖坑、 推倒重做；

  2.你永远不可预知产品经理和老板的idea，被动的接受摆布去实现各种合理、不合理的需求；

  3.业务拓展，需求变更；

  ......

以上任何事件的发生就注定了我们要加班，有位司机说，半夜打车的不是喝酒就是搞IT的。

四个阶段

1.面向对象编程思想

   什么是面向对象？什么是封装、继承和多态，以及三个特点的表现形式，基础很重要。

2.划分抽象与具体

    如何更好的解决“变化”问题？答案是“提取抽象、隔离具体”。
    什么是“抽象”？ 抽象就是不变的东西，一个数据表的操作，总会有增删改查，把他们作为接口，这是不变的。
    什么是“具体”？ 具体是实际执行的，一个数据表的增删改查，用sqlserver、access还是oracle？可能会有变化。
    我们应该依赖于抽象编程，而不是依赖于具体编程。应该把程序中的共性抽象出来，并且把具体实现的部分隔离开来， 让他们都依赖于抽象，并且互不影响。这其实就是设计。 只有理解了“抽象”、“具体”、“隔离”这几个词儿，你才能真正理解设计模式

3.理解设计原则

   单一职责原则：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
   开放封闭原则：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
   里氏替换法则：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
   依赖倒置原则：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
   接口分离原则：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
   迪 米 特 法 则：一个软件实体应当尽可能少地与其他实体发生相互作用。

4.运用设计模式

  最后才是设计模式，设计模式其实是一些工具而已。就如功夫里的招式，没有内功的沉淀和修炼，也只不过是空架子。

有人说几行代码的事情为什么搞的那么复杂？正如标题所写设计，为了更好的应对变化。

当你设计出一套优秀代码时，你会因为它不加班，因为它得到同事的赞许，因为它爱上编程。

附一位国外大牛的话：模式从不保证任何东西，它不能保证你一定能够做出可复用的软件，提高你的生产率，更不能保证世界和平， 模式并不能替代人来完成软件系统的创造，它们只不过会给那些缺乏经验但却具备才能和创造力的人带来希望。