你知道软件设计的6大原则吗？SOLID设计原则.doc

欢迎交流若擘_新浪博客B/robertlizhiqiang设计模式的基础是坚实的面向对象设计原则，我将以Robert Martin的S.O.L.I.D.设计原则为例来讲解这一点。本章还将介绍Martin Fowler的Patterns of Enterprise Application Architecture一书中提出的一些更高级的模式。设计比技术理重要，这一直是我想说的，这两天又在看设计模式，每一次看，每一次的感悟都不一样这六个设计原则，原本也是老生常谈了，但是，你写的每一步代码，都能做到这样的完美吗？如果没有，请再细细读一次深思吧若擘S.O.L.I.D.设计原则S.O.L.I.D.设计原则是一组针对面向对象设计的最佳实践。GoF设计模式均以这样或那样的形式遵守这些原则。术语S.O.L.I.D.来自于Robert C. Martin(朋友们亲切地称呼他Bob大叔)的著作Agile Principles, Patterns, and Practices in C#中收集的5个设计原则的名称的首字母。下面将依次介绍这些设计原则。1. 单一责任原则(SRP)SRP原则与SoC原则保持高度一致。它要求每个对象只应该为一个元素而改变而且只有一个职责关注点。遵循这个原则，就可以避免单体类(就像是软件领域的瑞士军刀)设计问题。使每个类均保持简洁，就可以提升系统的可读性和可维护性。2. 开放封闭原则(OCP)OCP原则要求类对于扩展应该是开放的，而对于修改应该是封闭的，这样应该就能够在不改变类的内部行为的情况下添加新功能并扩展类。这个原则努力避免破坏已有的类以及其他依赖它的类，因为这会在应用程序中造成bug和错误的涟漪效应。3. 里氏替换原则(LSP)LSP原则指出应该能够使用任何继承类来替代父类并且让其行为方式保持不变。这个原则与OCP原则保持一致：它确保继承类不会影响父类的行为，换句话来说，继承类必须可替代它们的基类。4. 接口分离原则(ISP)ISP原则关注的是将契约的方法划分成若干职责分组，并且为这些分组指派不同的接口，这样客户端就不需要实现一个庞大的接口和一堆它们并不使用的方法。这个原则背后的目的是：使用相同接口的类只需要实现特定的一组方法，而不是实现一个庞大的单体方法接口。5. 依赖倒置原则(DIP)DIP原则的宗旨是将自己编写的类与具体的实现隔离开来，让这些类依赖于抽象类或接口。它提倡面向接口(而不是实现)编程，这确保代码不会与某种实现紧密耦合，从而提高了系统的灵活性。6. 依赖注入(DI)和控制反转(IoC)原则与DIP紧密相关的是DI原则和IoC原则。DI通过构造器、方法或属性来提供底层类或从属类。配合使用DI原则，这些从属类可以被反转为接口或抽象类，这样就可以形成一个具有较高的可测试性和易于修改的松散耦合系统。在IoC原则中，系统的控制流与过程式编程方法相比是反转的。这个原则的一个示例是IoC容器，它的作用是将服务注入到客户端代码，而不必让客户端代码指定具体的实现。在该实例中，控制反转指的是客户端获取服务的行为。趣图解析：单一责任原则：当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。开放封闭原则软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。里氏替换原则当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系依赖倒置原则1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象2. 抽象不应该依赖于细节，细节应该依赖于抽象接口分离原则不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。这几条原则是非常基础而且重要的面向对象设计原则。正是由于这些原则的基