.net面向对象设计原则
稳定的框架来源于好的设计，好的设计才能出好的作品，掌握面向对象基本原则才会使我们的设计灵活、合理、不僵化，今天就来谈一谈我们.net 面向对象设计的基本原则。
对于一个没有任何设计经验的开发者来说，如果不假思索和探究式的去设计系统软件的框架，势必会导致系统代码出现这样或者那样的问题，比如：代码复杂和重复，不能剥离出独立的复用组件，系统不稳定等。通过灵活的设计原则，加上一定的设计模式，封装变化，降低耦合，实现软件的复用和扩展，这正是设计原则的最终意义。
我们都知道面向对象的三大要素是封装、继承和多态，这三大完整体系以抽象来封装变化，隐藏具体实现，保护内部信息；继承实现复用；多态改写对象行为。在此基础上我们来聊一聊.net中七大面向对象设计原则：
一、单一职责原则
系统好不好，强调的是模块间保持低耦合、高内聚的关系，面向对象设计原则第一条则是：单一职责原则（SRP）。
核心：单一职责原则强调的是职责分离，一个类应该只有一种引起它变化的原因，不应该将变化原因不同的职责封装在一起。
实现单一职责原则最好一个类只做一件事，职责过多，可能引起它变化的原因就很多，这将导致职责依赖，相互之间就会产生影响。
应用如下：
举一个项目中经常用到的例子，比如通过不同的权限来设计数据库不同的操作。
以上的设计中，把数据库的操作类和用户权限的判断封装在一个类中，设计就显得有点僵硬，因为权限的规则变化和数据库的规则变化都会改变DBManager类。好的设计是需要将二者分开，设计如下：
新增类DBManagerProxy，有效实现了职责分离，类DBAction至关注数据库操作，不用担心权限判断，使用职责分离的代码如下：
/// <summary>
/// 数据库操作实体
/// </summary>
public class DBAction : IDBAction
{
/// <summary>
/// 增加
/// </summary>
public void Add()
{
Console.WriteLine("Add Succeed");
}
/// <summary>
/// 删除
/// </summary>
/// <returns></returns>
public int Delete()
{
Console.WriteLine("Delete Succeed");
return ;
}
/// <summary>
/// 查询页面
/// </summary>
public void View()
{
}
}
DBAction类
/// <summary>
/// 权限判断和数据操作代理类
/// </summary>
public class DBManagerProxy : IDBAction
{
private IDBAction _dbManager = null;
public DBManagerProxy(IDBAction dbManager)
{
_dbManager = dbManager;
} /// <summary>
/// 获取权限
/// </summary>
/// <param name="id"></param>
/// <returns></returns>
public string GetPermission()
{
return "CanAdd,CanDelete";
} /// <summary>
/// 添加
/// </summary>
public void Add()
{
if (GetPermission().Contains("CanAdd"))
{
_dbManager.Add();
}
}
/// <summary>
/// 删除
/// </summary>
/// <returns></returns>
public int Delete()
{
int result = ;
if (GetPermission().Contains("CanDelete"))
{
result = _dbManager.Delete();
} return result;
}
/// <summary>
/// 查询页面
/// </summary>
public void View()
{
}
}
DBManagerProxy类
public class DBClient
{
public static void Main()
{ IDBAction dBAction = new DBManagerProxy(new DBAction());
dBAction.Add();
dBAction.Delete(); Console.ReadKey();
}
}
DBClient类
/// <summary>
/// 操作数据库接口
/// </summary>
public interface IDBAction
{
/// <summary>
/// 增加
/// </summary>
void Add();
/// <summary>
/// 删除
/// </summary>
/// <returns></returns>
int Delete();
/// <summary>
/// 查询页面
/// </summary>
void View();
}
IDBAction类
优点：模块间保持低耦合、高内聚的关系。
建议：SRP应该由引起变化的原因决定，而不是功能所决定的，这个需要自己在设计的过程中慎重权衡。
二、开放封闭原则
开放封闭原则（OCP）是面向对象原则的核心，软件本身就是封装变化，降低耦合，而开放封闭原则就是这一目标的直接体现。
核心：对扩展开放，对修改关闭。
在实际系统开发过程中需求是千变万化的，不是一成不变的，所以在一定程度上我们要满足系统本身的可扩展性，这就要求我们在设计能够灵活的扩展。实现这一原则的核心思想就是对抽象编程，而不是对具体编程。让类依赖于固定的抽象，所以对修改就是关闭的；通过对对象的继承和多态机制，实现新的扩展，所以是对扩展是开放的。
实际应用如下：
以上设计是机场售票业务，AirportStaff是业务员处理的业务类，AirportTicketProcess是客户信息类，设计中每个售票员都会面对买票、退票和咨询问题的客户，这样售票员不仅繁忙而且效率低下，在设计上更是拙劣，不利于扩展，为了更好地扩展，改造如下：
IAirportTicketProcess是抽象出来的机场业务接口，不管你是退票、查询还是买票都是业务的一种类型，那么我们只需继承该接口实现不同的业务即可，即便有新增业务类型，只需要继承该接口，仍然不影响原有设计，对于客户来说，根据自己的需求找对应的业务员处理，这样设计清晰职责单一。代码实现如下：
/// <summary>
/// 机场买票窗口接口
/// </summary>
public interface IAirportTicketProcess
{
/// <summary>
/// 业务处理
/// </summary>
void Process();
}
IAirportTicketProcess类
/// <summary>
/// 买票类
/// </summary>
public class CollectTicketProcess : IAirportTicketProcess
{
/// <summary>
/// 买票业务
/// </summary>
public void Process()
{
Console.WriteLine("只接受买票业务");
}
}
CollectTicketProcess类
/// <summary>
/// 查询票务类
/// </summary>
public class ReferTicketProcess : IAirportTicketProcess
{
/// <summary>
/// 查询票务业务
/// </summary>
public void Process()
{
Console.WriteLine("只接受票务查询业务");
}
}
ReferTicketProcess类
/// <summary>
/// 退票类
/// </summary>
public class RefoundTicketProcess : IAirportTicketProcess
{
/// <summary>
/// 退票业务
/// </summary>
public void Process()
{
Console.WriteLine("只接受退票业务");
}
}
RefoundTicketProcess类
/// <summary>
/// 业务员类
/// </summary>
public class AirportStaff
{
private IAirportTicketProcess _airportTicketProcess = null;
/// <summary>
/// 具体业务员操作的业务类
/// </summary>
public void HandleProcess(Client client)
{
_airportTicketProcess = client.CreateProcess();
_airportTicketProcess.Process();
}
}
AirportStaff类
/// <summary>
/// 客户类
/// </summary>
public class Client
{
private string _clientType;
public Client(string clientType)
{
_clientType = clientType;
}
/// <summary>
/// 客户业务处理判断
/// </summary>
/// <returns></returns>
public IAirportTicketProcess CreateProcess()
{
switch (_clientType)
{
case "查询客户":
return new ReferTicketProcess();
case "买票客户":
return new CollectTicketProcess();
case "退票客户":
return new RefoundTicketProcess();
} return null;
}
}
Client类
public class AirportProcess
{
public static void Main()
{ AirportStaff staff = new AirportStaff();
staff.HandleProcess(new Client("买票客户"));
staff.HandleProcess(new Client("查询客户"));
staff.HandleProcess(new Client("退票客户")); Console.ReadKey();
}
}
AirportProcess类
这种设计无论对业务员还是客户一切都变得简单而有序，如果新增挂失业务，只需要继承接口新增具体挂失类即可
/// <summary>
/// 挂失处理
/// </summary>
public class LossTicketProcess : IAirportTicketProcess
{
/// <summary>
/// 挂失处理
/// </summary>
public void Process()
{
Console.WriteLine("只接受挂失业务");
}
}
LossTicketProcess类
优点：有效降低实体与实体之间的耦合度；对容易变化的因素进行抽象处理，从而改善类的内聚性。
建议：封装变化是实现OCP的重要思路，对于经常发生变化的状态一般将其封装为一个抽象，同时拒绝乱用抽象，只将经常变化的部分进行抽象。
三、依赖倒置原则
核心：依赖存在于类与类、模块与模块之间，核心是依赖于抽象，具体体现在高层模块不应该依赖于底层模块，二者都应该依赖于接口， 抽象不应该依赖于具体，具体应该依赖于对象。缩写DIP
当两个模块发生紧耦合的关系时，最好的办法就是分离接口和实现：在依赖之间定义一个接口，使得高层模块调用接口，底层模块实现接口，达到依赖与抽象的目的。
实际应用如下：
在上述机场售票业务中，还有个不足之处就是在AirportStaff业务员处理的业务类依赖于客户类Client，这样就导致了业务依赖于客户类型，如果新增业务类型，就需要新增对客户的依赖。改造后如下：
可以把客户也抽象一个接口，不同的客户调用对应的业务。代码如下：
/// <summary>
/// 客户接口
/// </summary>
public interface IClient
{
IAirportTicketProcess CreateProcess();
}
IClient接口
/// <summary>
/// 买票客户
/// </summary>
public class CollectTicketClient : IClient
{
public IAirportTicketProcess CreateProcess()
{
return new CollectTicketProcess();
}
}
CollectTicketClient类
/// <summary>
/// 票务查询客户
/// </summary>
public class ReferTicketClient : IClient
{
public IAirportTicketProcess CreateProcess()
{
return new ReferTicketProcess();
}
}
ReferTicketClient类
/// <summary>
/// 退票客户
/// </summary>
public class ReFoundTicketClient : IClient
{
public IAirportTicketProcess CreateProcess()
{
return new RefoundTicketProcess();
}
}
ReFoundTicketClient类
public class AirportStaffNew
{
private IAirportTicketProcess _airportTicketProcess = null;
/// <summary>
/// 具体业务员操作的业务类
/// </summary>
public void HandleProcess(IClient client)
{
_airportTicketProcess = client.CreateProcess();
_airportTicketProcess.Process();
}
}
AirportStaffNew类
public class AirportProcessNew
{
public static void Main()
{ AirportStaffNew staff = new AirportStaffNew();
staff.HandleProcess(new ReFoundTicketClient());
staff.HandleProcess(new ReferTicketClient()); Console.ReadKey();
}
}
AirportProcessNew类
这样AirportStaffNew依赖于接口，更方便扩展。
优点：系统稳定，降低耦合度。
建议：依赖于抽象是一个通用的规则，特殊情况也会依赖于细节，必须权衡好抽象和具体的取舍。
四、接口隔离原则
核心：使用多个小的专门接口，不建议使用大的总接口。缩写ISP
这个比较好理解，我就直接上设计。
实际应用如下：
这个接口虽然功能都能实现要求，但是比较臃肿，更好地设计如下：
优点：有效的将抽象和细节分开。
建议：将功能相近的接口合并，可能造成接口污染，最好使用内聚的接口。
五、Liskov替换原则
又称里氏替换原则，是实现开放封闭原则的具体规范，这个大家只需要做一个了解。
核心：子类必须能够替换其基类。缩写LSP
它主要在继承机制中约束规范，子类必须能够替换其基类才能保证系统在运行期内识别子类，这是保证复用的基础。LSP要求基类是virtual方法那么子类中就必须重写该方法，如果子类有基类没有的方法或者成员都违反LSP原则。
优点：增强系统的扩展性，基于多态的机制能够减少代码冗余。
建议：子类必须满足基类和客户端对其的行为约定，子类的异常必须控制在基类可以预计的范围内。
六、合成/聚合复用原则
新对象中聚合已有的对象使之成为新对象的成员，少继承、多聚合。缩写CARP。
七、迪米特法则
最少知道原则，软件实体应该尽可能少的和其他软件实体发生相互作用。缩写LoD。
以上是我对.NET面向对象设计原则的总结，欢迎纠错。
最新文章
- Java--笔记（6）
- ios8调用相机报警告: Snapshotting a view that has not been rendered results in an empty snapshot. Ensure you(转)
- 其他窗体赋值给comboBox实现值的回显，并使赋的值处于选中状态（根据text获取selectedindex）
- Linux基础--例行工作
- Six important .NET concepts 【Turn】
- HDU2149-Good Luck in CET-4 Everybody!(博弈，打表找规律)
- UIAlertView弹出框
- Jwalk发布——一个比较小的Js动画库
- 面向对象和面向过程，python中的类class，python中程序的入口——main方法，
- IDEA中使用lombok插件
- 重写$.ajax方法
- UML类图实例分析
- dhcp服务器（一）
- Luogu P2341 [HAOI2006]受欢迎的牛
- 数据驱动测试二：使用TestNG和CSV文件进行数据驱动
- ROC曲线与AUC
- docker使用现有容器生成新的镜像
- CSS3-阴影参数基础
- jspSmartUpload上传下载使用例子
- 设计模式之笔记--建造者模式（Builder）