设计模式的师祖GoF，有句名言：Program to an interface, not an implementation，表示对接口编程而不要对实现编程，更通俗的说法是对抽象编程而不要对具体编程。关于面向对象和设计原则，将始终强调对抽象编程的重要性，这源于抽象代表了系统中相对稳定并又能够通过多态特性对其扩展，这很好地符合了高内聚、低耦合的设计思想。以著名的Petshop 4.0中一个简单的面向对象设计片段为例，来诠释面向接口编程的奥秘。 在Petshop 4.0的数据访问层设计上，微软设计师将较为基础的增删改查操作封装为接口，由具体的实体操作类来实现。抽象出的单独接口模块，使得对于数据的操作和业务逻辑对象相分离。

借鉴这种设计思路实现一个简单的用户操作数据访问层，通过接口将增删改查封装起来，再由具体的MySQLUser、AccessUser和XMLUser来实现，Helper类则提供了操作数据的通用方法。基于接口的数据访问层和具体的数据操作实现彻底隔离，对数据的操作规则的变更不会影响实体类对象的行为，体现了职责分离的设计原则，而这种机制是通过接口来完成的。 同时，能够以IUser接口来统一处理用户操作，例如在具体的实例创建时，可以借助反射机制，通过依赖注入来设计实现：

 public sealed class DataAccessFactory { private static readonly string assemblyPath = ConfigurationManager.AppSettings ["AssemblyPath"]; private static readonly string accessPath = ConfigurationManager.AppSettings ["AccessPath"]; public static IUser CreateUser() { string className = accessPath + ".User"; return (IUser)Assembly.Load(assemblyPath).CreateInstance(className); } }

你看，通过抽象可以将未知的对象表现出来，通过读取配置文件的相关信息可以很容易创建具体的对象，当有新的类型增加时不需要对原来的系统做任何修改只要在配置文件中增加相应的类型全路径即可。这种方式体现了面向接口编程的另一个好处：对修改封闭而对扩展开放。 正是基于这种设计才形成了数据访问层、业务逻辑层和表现层三层架构的良好设计。而数据访问层是实现这一架构的基础，在业务逻辑层，将只有实体对象的相互操作，而不必关心具体的数据库操作实现，甚至看不到任何SQL语句执行的痕迹，例如： public class BLL { private static readonly IUser user = DataAccessFactory.CreateUser(); private static User userInfo = new User(); public static void HandleUserInfo(string ID) { userInfo = user.GetUser(ID); //对userInfo实体对象进行操作} } 另外，按照接口隔离原则，接口应该被实现为具有单一功能的多个小接口，而不是具有多个功能的大接口。通过多个接口的不同组合，客户端按需实现不同的接口，从而避免出现接口污染的问题。

ASP.NET：C#.Net程序开发中的Socket介绍 ASP.NET：.Net参数基础论

评论 (0) All