What
设计模式(Design Pattern)是前人针对面向对象设计中反复出现的问题，总结出的设计套路。这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。
算法不是DP，算法致力于解决本质问题，而DP更侧重布局设计问题；DP不能让算法变得更准确或者更高效，但可能会让算法实现的更优雅(好吧，更可复用、好维护、易扩展、更可靠等)。
Why
正确使用设计模式具有以下优点。
6大设计原则（对封装、继承、多态的进一步原则指导）开闭原则
软件实体应当对扩展开放，对修改关闭（避免影响已有的逻辑）
软件实体包括以下几个部分：
实现方法：抽象约束、封装变化
即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。
而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。
举例：Windows 的桌面主题设计
单一职责原则
类的职责尽量专注单一，从而达到高内聚低耦合
该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：
实现方式：找准核心实体，发现多重职责，进行分离
单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。
而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。
举例 ：学生工作
分析：大学学生工作主要包括学生生活辅导和学生学业指导两个方面的工作，其中生活辅导主要包括班委建设、出勤统计、心理辅导、费用催缴、班级管理等工作，学业指导主要包括专业引导、学习辅导、科研指导、学习总结等工作。如果将这些工作交给一位老师负责显然不合理，正确的做 法是生活辅导由辅导员负责，学业指导由学业导师负责
里氏替换原则
只要父类出现的地方子类就可以出现，且替换成子类也不会出现任何错误或者异常（没事别瞎继承！！）
子类可以扩展父类的功能，但不能改变父类原有的功能。
实现方式：取消原来的继承关系，重新设计它们之间的关系
举例：几维鸟不是鸟”
不合理的继承关系：
不符合里氏替换的继承
较合理的继承关系：
符合里氏替换的继承
依据：
鸟一般都会飞行，如燕子的飞行速度大概是每小时 120 千米。但是新西兰的几维鸟由于翅膀退化无法飞行。假如要设计一个实例，计算这两种鸟飞行 300 千米要花费的时间。显然，拿燕子来测试这段代码，结果正确，能计算出所需要的时间；但拿几维鸟来测试，结果会发生“除零异常”或是“无穷大”，明显不符合预期
正确的做法是：取消几维鸟原来的继承关系，定义鸟和几维鸟的更一般的父类，如动物类，它们都有奔跑的能力。几维鸟的飞行速度虽然为 0，但奔跑速度不为 0，可以计算出其奔跑 300 千米所要花费的时间。
依赖倒置原则
面向接口编程，而非面向实现编程（高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象）；这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。
实现
举例：顾客购物程序
接口隔离原则
不要建立臃肿庞大的接口。即接口尽量细化，客户端不应该被迫依赖于它不使用的方法；
实现
举例：学生成绩管理程序
学生成绩管理程序一般包含插入成绩、删除成绩、修改成绩、计算总分、计算均分、打印成绩信息、査询成绩信息等功能，如果将这些功能全部放到一个接口中显然不太合理，正确的做法是将它们分别放在输入模块、统计模块和打印模块等 3 个模块中。
迪米特法则
一个对象应该对其他对象（接口、参数、返回值等）有最少的了解（为了解耦、安全等）
但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。
实现
从依赖者的角度来说，只依赖应该依赖的对象。
从被依赖者的角度说，只暴露应该暴露的方法。
举例：明星与经纪人的关系实例
明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则
组成聚合原则
它要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
实现
合成复用原则是通过将已有的对象纳入新对象中，作为新对象的成员对象来实现的，新对象可以调用已有对象的功能，从而达到复用。
举例：汽车分类管理
汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。
不好的设计
不好的设计
推荐的设计
推荐的设计
发表评论