在设计程序、系统框架或者类时，最主要考虑的事情就是代码的可扩展性，而不是完成功能即可。因此，提倡使用面向对象设计的最佳实践和基本原则。

1.       单一职责原则（SRP：The Single Responsibility Principle）

　　对象应承担单一的责任，它们的行为应该关注在它的责任上。比如，视图应该只关注UI的渲染，而不需要任何数据访问逻辑。

通常，代码中要提防的是名称为XXXManager的类，这种类可能包含了更多的职责。

2.       开放封闭原则（OCP：Open Closed Principle）

　　鼓励对外扩展开发，对修改关闭。尽量通过继承类来扩展其功能，而不是像类中添加更多的行为和责任，这一原则算对SRP原则的补充。

3.       里氏替换原则（LSP：Liskov Substitution Principle）

　　对象应易于被其子类型的实例替换，而不会影响对象的行为和规则。

4.       接口隔离原则（ISP：Interface Segregation Principle）

　　鼓励在整个应用程序中使用接口的同时，也需要限制接口的大小。即，接口应该是更小、更多的特定接口，而不是一个包含所有对象行为的超类接口。接口的设计应该遵循SRP原则。

5.       依赖倒置原则（DIP：Dependency Inversion Principle）

　　互相依赖的组件应该通过抽象来实现交互，而不是直接通过具体来实现。最直接的例子，就是将一切依赖都设置为抽象类或接口，而不是该类的具体实例。

DIP的优点：使用抽象可允许不同的组件进行独立开发、修改和测试。

6.       控制反转（IOC：Inversion of Control）

　　严格来说，IOC与上面5个设计原则不是对等关系，它应该是将5大原则整合使用的一个原则。

　　IOC是一种提倡实现松耦合层、组件和类的设计原则，它颠倒了应用程序的控制流程。传统的程序代码显示控制调用的过程，而IOC则使用分离执行特定问题处理代码，它允许独立开发程序的各个组件。

　　目前，IOC的两个流行实现就是依赖注入（Dependency Injection）和服务定位（Service Location）。这两种方式都是相同的中心容器的概念来管理依赖项的生命周期。而不同的是，服务定位依赖调用者调用依赖，而依赖注入通过类的构造函数、属性或执行方法来实现。

理解依赖关系

　　减少程序复杂性的关键是了解程序中的依赖关系，并合理地管理其依赖关系。依赖关系有多种形式：程序集引用一个或多个其他程序集，子类必须继承父类。

以一个控制访问数据服务获取数据的例子说明IOC的一步步改进：

直接调用阶段	控制器直接创建数据服务的一个实例，因此，控制器与数据服务之间紧密耦合，对数据库层的修改可能会影响到控制器。
使用工厂模式	为了降低控制器和数据服务的耦合度，使用接口IDataService并把创建服务的代码移动到工厂模式中，控制器和DataService依赖于IDataService接口，接口不变的情况，DataService的修改不会影响到控制器，从而消除了控制器和DataService的紧耦合，但是控制器和工厂类之间存在依赖关系。
IOC模式	控制器仍使用IDataService接口作为抽象，但是控制器不知道IDataService实例如何创建的，它是由IOC容器负责创建并传递（注入）到控制器的IDataService实例上，程序其他位置需要提供IOC容器的配置来实现类实例的声明周期管理。