编写软件过程中，面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序，具有更好的代码重用性、可读性、可扩展性、可靠性，使程序呈现高内聚低耦合的特性。
软件设计的“七宗罪”：
- 僵化性
- 脆弱性
- 牢固性
- 粘滞性
- 不必要的重复
- 不必要的复杂性
- 晦涩性
1. 僵化性
僵化性是指难以对软件进行改动，即使是简单的改动。如果单一的改动会导致有依赖关系的模块中的连锁改动，那么设计就是僵化的。必须要改动的模块越多，设计就越僵化。
2. 脆弱性
脆弱性是指在进行一个改动时，程序的许多地方就可能出现问题，即设计易于遭破坏。并且，往往是出现新问题的地方与改动的地方并没有概念上的关联。
3. 牢固性
牢固性是指设计中包含了对其他系统有用的部分，但要想把这些部分分离出来所需要的努力和风险是巨大的，即设计难以复用。
4. 粘滞性
有的时候，一个改动可以以保持原有的设计意图和原有的设计框架的方式进行，也可以以破坏原始的意图和框架的方式进行。第一种办法无疑会对系统的未来有利，第二种办法是去权宜之计，可以解决短期问题，但是会牺牲长期利益。如果第二种办法比第一种办法容易得多的话，程序员就有可能牺牲长期利益，采取权宜之计，在一个通用的逻辑中建立一种特例，以便解决眼前的问题。一个系统的设计，如果总是使得第二种办法比第一种办法来得容易，说明粘滞性过高。一个粘滞性过高的系统会诱使维护它的程序员采取错误的维护方案。
5. 不必要的重复
大量的重复代码往往是由于开发人员忽略了抽象，从而使系统不易理解，而且，软件中的重复代码，也会使系统的改动变得困难，不易于系统的维护。
6. 不必要的复杂性
不必要的复杂性是指设计中包含了当前没有用的部分，即过分设计。例如，对于逻辑复杂、技术先进的过度追求，导致了技术框架虽看似华丽却复杂难用。再例如，在设计产品功能或界面交互时，过度追求体验完美、需求满足却导致实际体验下降、功能没人用。所以，软件设计应“有所为有所不为”。
7. 晦涩性
晦涩性是指模块难于理解。代码随时间而不断演化，往往会变得越来越晦涩、可读性差。代码晦涩难懂常体现在如下几点：
- 代码不良
- 代码的格式不正确或不一致
- 代码中包含冗余代码
- 代码中包含未备注的低层次优化
- 代码逻辑过于复杂
设计模式七大原则有：
- 单一职责原则
- 接口隔离原则
- 依赖倒置原则
- 里氏替换原则
- 开闭原则
- 迪米特法则
- 合成复用原则
1. 单一职责原则
单一职责原则SRP（The Single Responsibility Principle）指的就是一个类应该仅有一个引起它变化的原因。这是最简单、最容易理解却最不容易做到的一个设计原则。
对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2。
单一职责原则注意事项和细节：
- 降低类的复杂度，一个类只负责一项职责。
- 提高类的可读性，可维护性
- 降低变更引起的风险
2. 接口隔离原则
接口隔离原则ISP（The Interface Segregation Principle）指的是“客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上”。就是说，“不应该强迫客户依赖于它们不用的方法”。再通俗点说，不要强迫客户使用它们不用的方法，如果强迫客户使用它们不需要的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
下面是一个违反了接口隔离原则的例子：
如果我们保持上面那样的设计，那么Robot类就将被迫实现eat()方法，当然我们可以写一个哑类让它什么也不做，但是这会对程序造成不可预料的结果，例如管理者看到 表中显示被带走的午餐多于实际的人数。
通过接口隔离原则，我们应该把IWorker分离成两个接口，如果Robot类需要添加特有而工人没有的方法，例如充电功能，我们可以再创建一个新的IRechargeable接口，其中包含一个重新充电的方法recharge。
更改后的代码如下：
总之，接口隔离原则是对接口进行规范约束，其包含以下含义：
- 接口尽量要小，这是接口隔离原则的核心定义，不要出现臃肿的接口
- 接口要高内聚
- 定制服务，只提供访问者需要的方法
- 接口设计是有限度的
3. 依赖倒置原则
依赖倒置原则DIP（The Dependency Inversion Principle）指的是“高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖于细节，细节应该依赖于抽象”。
好抽象的定义，我们直接上代码，先看一个不符合DIP原则的例子
public interface Switchable { void turnOn(); void turnOff();}public abstract class Light implements Switchable {}public abstract class TV implements Switchable {}public class BulbLight extends Light { @Override public void turnOn() {System.out.println("BulbLight turned on..."); } @Override public void turnOff() {System.out.println("BulbLight turned off..."); }}public class TubeLight extends Light { @Override publi
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！