面向对象设计原则
1、单一职责原则
就一个类而言，应该仅有一个引起它变化的原因。
类只因一个原因而变化，这仿佛是一种新的类定义方式。当接触面向对象编程时，试图把一个类对比为一个事物，事物具备的功能都是这个类的操作。比如，一根尺子，既可以用来打学生手板，也可以用来丈量布匹。而在单一职责原理下，尺子的两个功能就是引起这个类变化的两个原因，就应该写成两个类。
如果混在一起写，在修改一个职责的时候，可能会影响到另一个职责。当另一个类只使用其中一个职责的时候，另一不会用到的职责会消耗掉更多的资源。
举个Bob大叔给的例子，电话的interface有3个。其中dial和hangup是负责语音通信的，而chat是负责数据业务的。应该把这两个可能单独存在的职责分开。如果一个电话同时具备两个职责，可以让它实现两个接口。
联想到TDD，TDD总是从需求着手，为一条需求写测试代码，然后写产品代码。一条需求可以理解为一个变化，这样极大促成了第一个写出来的类是符合单一职责原则。能较为有效的避免产生多职责类。
2、开放封闭原则OCP
定义：是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。
开闭原则主要体现在两个方面：
1、对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
2、对修改封闭，意味着类一旦设计完成，就可以独立其工作，而不要对类做任何修改。
为什么要用到开放封闭原则呢？
软件需求总是变化的，世界上没有一个软件的是不变的，因此对软件设计人员来说，必须在不需要对原有系统进行修改的情况下，实现灵活的系统扩展。
如何做到对扩展开放，对修改封闭呢？
实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。
对于违反这一原则的类，必须通过重构来进行改善。常用于实现的设计模式主要有Template Method模式和Strategy 模式。而封装变化，是实现这一原则的重要手段，将经常变化的状态封装为一个类。
以银行业务员为例：
没有实现OCP设计的： java语言
public class BankProcess
{
public void Deposite(){} //存款
public void Withdraw(){} //取款
public void Transfer(){} //转账
}
public class BankStaff
{
private BankProcess bankpro = new BankProcess();
public void BankHandle(Client client)
{
switch (client .Type)
{
case "deposite": //存款
bankpro.Deposite();
break;
case "withdraw": //取款
bankpro.Withdraw();
break;
case "transfer": //转账
bankpro.Transfer();
break;
}
}
}如何才能实现耦合度和灵活性兼得呢？
那就是抽象，将业务功能抽象为接口，当业务员依赖于固定的抽象时，对修改就是封闭的，而通过继承和多态继承，从抽象体中扩展出新的实现，就是对扩展的开放。
以下是符合OCP的设计：
//首先声明一个业务处理接口
public interface IBankProcess//抽象类
{
void Process();
}
public class DeposiProcess:IBankProcess//继承类
{
public void Process() //办理存款业务
{
Console.WriteLine("Process Deposit");
}
}
public class WithDrawProcess:IBankProcess
{
public void Process() //办理取款业务
{
Console.WriteLine("Process WithDraw");
}
}
public class TransferProcess:IBankProcess
{
public void Process() //办理转账业务
{
Console .WriteLine ("Process Transfer")；
}
}
public class BankStaff
{
private IBankProcess bankpro = null ;
public void BankHandle(Client client)
{
switch (client .Type)
{
case "Deposite": //存款
userProc =new WithDrawUser();
break;
case "WithDraw": //取款
userProc =new WithDrawUser();
break;
case "Transfer": //转账
userProc =new WithDrawUser();
break;
}
userProc.Process();
}
}3、依赖倒置原则
抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对抽象（接口）编程，而不是针对实现细节编程。
- 高层模块不应该依赖低层模块，两者都应该依赖抽象
- 抽象不应该依赖细节
- 细节应该依赖抽象