稳定的框架来源于好的设计，好的设计才能出好的作品，掌握面向对象基本原则才会使我们的设计灵活、合理、不僵化，今天就来谈一谈我们.net 面向对象设计的基本原则。
对于一个没有任何设计经验的开发者来说，如果不假思索和探究式的去设计系统软件的框架，势必会导致系统代码出现这样或者那样的问题，比如：代码复杂和重复，不能剥离出独立的复用组件，系统不稳定等。通过灵活的设计原则，加上一定的设计模式，封装变化，降低耦合，实现软件的复用和扩展，这正是设计原则的最终意义。
我们都知道面向对象的三大要素是封装、继承和多态，这三大完整体系以抽象来封装变化，隐藏具体实现，保护内部信息；继承实现复用；多态改写对象行为。在此基础上我们来聊一聊.net中七大面向对象设计原则：
一、单一职责原则
系统好不好，强调的是模块间保持低耦合、高内聚的关系，面向对象设计原则第一条则是：单一职责原则（SRP）。
核心：单一职责原则强调的是职责分离，一个类应该只有一种引起它变化的原因，不应该将变化原因不同的职责封装在一起。
实现单一职责原则最好一个类只做一件事，职责过多，可能引起它变化的原因就很多，这将导致职责依赖，相互之间就会产生影响。
应用如下：
举一个项目中经常用到的例子，比如通过不同的权限来设计数据库不同的操作。
以上的设计中，把数据库的操作类和用户权限的判断封装在一个类中，设计就显得有点僵硬，因为权限的规则变化和数据库的规则变化都会改变DBManager类。好的设计是需要将二者分开，设计如下：
新增类DBManagerProxy，有效实现了职责分离，类DBAction至关注数据库操作，不用担心权限判断，使用职责分离的代码如下：
1 /// <summary> 2 /// 数据库操作实体 3 /// </summary> 4 public class DBAction : IDBAction 5 { 6 /// <summary> 7 /// 增加 8 /// </summary> 9 public void Add() 10 { 11 Console.WriteLine("Add Succeed"); 12 } 13 /// <summary> 14 /// 删除 15 /// </summary> 16 /// <returns></returns> 17 public int Delete() 18 { 19 Console.WriteLine("Delete Succeed"); 20 return 1; 21 } 22 /// <summary> 23 /// 查询页面 24 /// </summary> 25 public void View() 26 { 27 } 28 }
1 /// <summary> 2 /// 权限判断和数据操作代理类 3 /// </summary> 4 public class DBManagerProxy : IDBAction 5 { 6 private IDBAction _dbManager = null; 7 public DBManagerProxy(IDBAction dbManager) 8 { 9 _dbManager = dbManager; 10 } 11 12 /// <summary> 13 /// 获取权限 14 /// </summary> 15 /// <param name="id"></param> 16 /// <returns></returns> 17 public string GetPermission() 18 { 19 return "CanAdd,CanDelete"; 20 } 21 22 /// <summary> 23 /// 添加 24 /// </summary> 25 public void Add() 26 { 27 if (GetPermission().Contains("CanAdd")) 28 { 29 _dbManager.Add(); 30 } 31 } 32 /// <summary> 33 /// 删除 34 /// </summary> 35 /// <returns></returns> 36 public int Delete() 37 { 38 int result = 0; 39 if (GetPermission().Contains("CanDelete")) 40 { 41 result = _dbManager.Delete(); 42 } 43 44 return result; 45 } 46 /// <summary> 47 /// 查询页面 48 /// </summary> 49 public void View() 50 { 51 } 52 }
1 public class DBClient 2 { 3 public static void Main() 4 { 5 6 IDBAction dBAction = new DBManagerProxy(new DBAction()); 7 dBAction.Add(); 8 dBAction.Delete(); 9 10 Console.ReadKey(); 11 } 12 }
1 /// <summary> 2 /// 操作数据库接口 3 /// </summary> 4 public interface IDBAction 5 { 6 /// <summary> 7 /// 增加 8 /// </summary> 9 void Add(); 10 /// <summary> 11 /// 删除 12 /// </summary> 13 /// <returns></returns> 14 int Delete(); 15 /// <summary> 16 /// 查询页面 17 /// </summary> 18 void View(); 19 }
优点：模块间保持低耦合、高内聚的关系。
建议：SRP应该由引起变化的原因决定，而不是功能所决定的，这个需要自己在设计的过程中慎重权衡。
二、开放封闭原则
开放封闭原则（OCP）是面向对象原则的核心，软件本身就是封装变化，降低耦合，而开放封闭原则就是这一目标的直接体现。
核心：对扩展开放，对修改关闭。
在实际系统开发过程中需求是千变万化的，不是一成不变的，所以在一定程度上我们要满足系统本身的可扩展性，这就要求我们在设计能够灵活的扩展。实现这一原则的核心思想就是对抽象编程，而不是对具体编程。让类依赖于固定的抽象，所以对修改就是关闭的；通过对对象的继承和多态机制，实现新的扩展，所以是对扩展是开放的。
实际应用如下：
以上设计是机场售票业务，AirportStaff是业务员处理的业务类，AirportTicketProcess是客户信息类，设计中每个售票员都会面对买票、退票和咨询问题的客户，这样售票员不仅繁忙而且效率低下，在设计上更是拙劣，不利于扩展，为了更好地扩展，改造如下：
IAirportTicketProcess是抽象出来的机场业务接口，不管你是退票、查询还是买票都是业务的一种类型，那么我们只需继承该接口实现不同的业务即可，即便有新增业务类型，只需要继承该接口，仍然不影响原有设计，对于客户来说，根据自己的需求找对应的业务员处理，这样设计清晰职责单一。代码实现如下：
1 /// <summary> 2 /// 机场买票窗口接口 3 /// </summary> 4 public interface IAirportTicketProcess 5 { 6 /// <summary> 7 /// 业务处理 8 /// </summary> 9 void Process(); 10 }
1 /// <summary> 2 /// 买票类 3 /// </summary> 4 public class CollectTicketProcess : IAirportTicketProcess 5 { 6 /// <summary> 7 /// 买票业务 8 /// </summary> 9 public void Process() 10 { 11 Console.WriteLine("只接受买票业务"); 12 } 13 }
1 /// <summary> 2 /// 查询票务类 3 /// </summary> 4 public class ReferTicketProcess : IAirportTicketProcess 5 { 6 /// <summary> 7 /// 查询票务业务 8 /// </summary> 9 public void Process() 10 { 11 Console.WriteLine("只接受票务查询业务"); 12 } 13 }
1 /// <summary> 2 /// 退票类 3 /// </summary> 4 public class RefoundTicketProcess : IAirportTicketProcess 5 { 6 /// <summary> 7 /// 退票业务 8 /// </summary> 9 public void Process() 10 { 11 Console.WriteLine("只接受退票业务"); 12 } 13 }
1 /// <summary> 2 /// 业务员类 3 /// </summary> 4 public class AirportStaff 5 { 6 private IAirportTicketProcess _airportTicketProcess = null; 7 /// <summary> 8 /// 具体业务员操作的业务类 9 /// </summary> 10 public void HandleProcess(Client client) 11 { 12 _airportTicketProcess = client.CreateProcess(); 13 _airportTicketProcess.Process(); 14 } 15 }
1 /// <summary> 2 /// 客户类 3 /// </summary> 4 public class Client 5 { 6 private string _clientType; 7 public Client(string clientType) 8 { 9 _clientType = clientType; 10 } 11 /// <summary> 12 /// 客户业务处理判断 13 /// </summary> 14 /// <returns></returns> 15 public IAirportTicketProcess CreateProcess() 16 { 17 switch (_clientType) 18 { 19 case "查询客户": 20 return new ReferTicketProcess(); 21 case "买票客户": 22 return new CollectTicketProcess(); 23 case "退票客户": 24 return new RefoundTicketProcess(); 25 } 26 27 return null; 28 } 29 }
1 public class AirportProcess 2 { 3 public static void Main() 4 { 5 6 AirportStaff staff = new AirportStaff(); 7 staff.HandleProcess(new Client("买票客户")); 8 staff.HandleProcess(new Client("查询客户")); 9 staff.HandleProcess(new Client("退票客户")); 10 11 Console.ReadKey(); 12 } 13 }
这种设计无论对业务员还是客户一切都变得简单而有序，如果新增挂失业务，只需要继承接口新增具体挂失类即可
1 /// <summary> 2 /// 挂失处理 3 /// </summary> 4 public class LossTicketProcess : IAirportTicketProcess 5 { 6 /// <summary> 7 /// 挂失处理 8 /// </summary> 9 public void Process() 10 { 11 Console.WriteLine("只接受挂失业务"); 12 } 13 }
优点：有效降低实体与实体之间的耦合度；对容易变化的因素进行抽象处理，从而改善类的内聚性。
建议：封装变化是实现OCP的重要思路，对于经常发生变化的状态一般将其封装为一个抽象，同时拒绝乱用抽象，只将经常变化的部分进行抽象。
三、依赖倒置原则
核心：依赖存在于类与类、模块与模块之间，核心是依赖于抽象，具体体现在高层模块不应该依赖于底层模块，二者都应该依赖于接口， 抽象不应该依赖于具体，具体应该依赖于对象。缩写DIP
当两个模块发生紧耦合的关系时，最好的办法就是分离接口和实现：在依赖之间定义一个接口，使得高层模块调用接口，底层模块实现接口，达到依赖与抽象的目的。
实际应用如下：
在上述机场售票业务中，还有个不足之处就是在AirportStaff业务员处理的业务类依赖于客户类Client，这样就导致了业务依赖于客户类型，如果新增业务类型，就需要新增对客户的依赖。改造后如下：
可以把客户也抽象一个接口，不同的客户调用对应的业务。代码如下：
1 /// <summary> 2 /// 客户接口 3 /// </summary> 4 public interface IClient 5 { 6 IAirportTicketProcess CreateProcess(); 7 }
1 /// <summary> 2 /// 买票客户 3 /// </summary> 4 public class CollectTicketClient : IClient 5 { 6 public IAirportTicketProcess CreateProcess() 7 { 8 return new CollectTicketProcess(); 9 } 10 }
1 /// <summary> 2 /// 票务查询客户 3 /// </summary> 4 public class ReferTicketClient : IClient 5 { 6 public IAirportTicketProcess CreateProcess() 7 { 8 return new ReferTicketProcess(); 9 } 10 }
1 /// <summary> 2 /// 退票客户 3 /// </summary> 4 public class ReFoundTicketClient : IClient 5 { 6 public IAirportTicketProcess CreateProcess() 7 { 8 return new RefoundTicketProcess(); 9 } 10 }
1 public class AirportStaffNew 2 { 3 private IAirportTicketProcess _airportTicketProcess = null; 4 /// <summary> 5 /// 具体业务员操作的业务类 6 /// </summary> 7 public void HandleProcess(IClient client) 8 { 9 _airportTicketProcess = client.CreateProcess(); 10 _airportTicketProcess.Process(); 11 } 12 }
1 public class AirportProcessNew 2 { 3 public static void Main() 4 { 5 6 AirportStaffNew staff = new AirportStaffNew(); 7 staff.HandleProcess(new ReFoundTicketClient()); 8 staff.HandleProcess(new ReferTicketClient()); 9 10 Console.ReadKey(); 11 } 12 }
这样AirportStaffNew依赖于接口，更方便扩展。
优点：系统稳定，降低耦合度。
建议：依赖于抽象是一个通用的规则，特殊情况也会依赖于细节，必须权衡好抽象和具体的取舍。
四、接口隔离原则
核心：使用多个小的专门接口，不建议使用大的总接口。缩写ISP
这个比较好理解，我就直接上设计。
实际应用如下：
这个接口虽然功能都能实现要求，但是比较臃肿，更好地设计如下：
优点：有效的将抽象和细节分开。
建议：将功能相近的接口合并，可能造成接口污染，最好使用内聚的接口。
五、Liskov替换原则
又称里氏替换原则，是实现开放封闭原则的具体规范，这个大家只需要做一个了解。
核心：子类必须能够替换其基类。缩写LSP
它主要在继承机制中约束规范，子类必须能够替换其基类才能保证系统在运行期内识别子类，这是保证复用的基础。LSP要求基类是virtual方法那么子类中就必须重写该方法，如果子类有基类没有的方法或者成员都违反LSP原则。
优点：增强系统的扩展性，基于多态的机制能够减少代码冗余。
建议：子类必须满足基类和客户端对其的行为约定，子类的异常必须控制在基类可以预计的范围内。
六、合成/聚合复用原则
新对象中聚合已有的对象使之成为新对象的成员，少继承、多聚合。缩写CARP。
七、迪米特法则
最少知道原则，软件实体应该尽可能少的和其他软件实体发生相互作用。缩写LoD。
以上是我对.NET面向对象设计原则的总结，欢迎纠错。