趣味编程:C#中Specification模式的实现(参考答案 - 上)
2009-09-28 10:34 by 老赵, 13334 visitsSpecification模式的作用是构建可以自由组装的业务逻辑元素。不过就上篇文章的示例来看,“标准”的Specification模式的实现还是比较麻烦的,简单的功能也需要较复杂的代码。不过,既然说是“标准”的方式,自然就是指可以在任意面向对象语言中使用的实现方式,不过我们使用的是C#,在实际开发过程中,我们可以利用C#如今的强大特性来实现出更容易使用,更轻量级的Specification模式。
当然,有利也有弊,在使用“标准”还是“轻量级”的问题上,还要根据你的需求来进行选择。
Specification模式的关键在于,Specification类有一个IsSatisifiedBy函数,用于校验某个对象是否满足该Specification所表示的条件。多个Specification对象可以组装起来,并生成新Specification对象,这便可以形成高度可定制的业务逻辑。从中可以看出,一个Specification对象的关键,其实就是一个IsSatisifiedBy方法的逻辑。每种对象,一段逻辑。每个对象的唯一关键,也就是这么一段逻辑。因此,我们完全可以构造这么一个“通用”的类型,允许外界将这段逻辑通过构造函数“注入”到Specification对象中:
public class Specification<T> : ISpecification<T> { private Func<T, bool> m_isSatisfiedBy; public Specification(Func<T, bool> isSatisfiedBy) { this.m_isSatisfiedBy = isSatisfiedBy; } public bool IsSatisfiedBy(T candidate) { return this.m_isSatisfiedBy(candidate); } }
嗯嗯,这也是一种依赖注入。在普通的面向对象语言中,承载一段逻辑的最小单元只能是“类”,只是我们说,某某类中的某某方法就是我们需要的逻辑。而在C#中,从最早开始就有“委托”这个东西可用来承载一段逻辑。与其为每种情况定义一个特定的Specification类,让那个Spcification类去访问外部资源(即建立依赖),不如我们将这个类中唯一需要的逻辑给准备好,各种依赖直接通过委托由编译器自动保留,然后直接注入到一个“通用”的类中。很关键的是,这样在编程方面也非常容易。
至于原本ISpecification<T>中的And,Or,Not方法,我们可以将它们提取成扩展方法。有朋友说,既然有了扩展方法,那么对于一些不需要访问私有成员/状态的方法,都应该提取到实体的外部,避免“污染”实体。不过我不同意,在我看来,到底是用实例方法还是扩展方法,还是个根据职责和概念而一定的。我在这里打算使用扩展的目的,是因为And,Or,Not并非是一个Specification对象的逻辑,并不是一个Specification对象说,“我要去And另一个”,“我要去Or另一个”,或者“我要造……取反”。就好比二元运算符&&、||、或者+、-,左右两边的运算数字有主次之分吗?没有,它们是并列的。因此,我选择使用额外的扩展方法,而不是将这些职责交给某个Specification对象:
public static class SpecificationExtensions { public static ISpecification<T> And<T>( this ISpecification<T> one, ISpecification<T> other) { return new Specification<T>(candidate => one.IsSatisfiedBy(candidate) && other.IsSatisfiedBy(candidate)); } public static ISpecification<T> Or<T>( this ISpecification<T> one, ISpecification<T> other) { return new Specification<T>(candidate => one.IsSatisfiedBy(candidate) || other.IsSatisfiedBy(candidate)); } public static ISpecification<T> Not<T>(this ISpecification<T> one) { return new Specification<T>(candidate => !one.IsSatisfiedBy(candidate)); } }
此外,使用扩展方法的好处在于,如果我们想要加一个逻辑运算(如“异或”),那么是不需要修改接口的。修改接口是一件劳民伤财的事情。
至此,我们使用Specification对象就容易多了,因为不需要为每段逻辑创建一个独立的ISpecification<T>类型。但是,其实还有更简单的:直接使用委托。既然整个Specificaiton对象的逻辑可以使用一个委托直接表示,那为什么我们还需要一个“外壳”呢?不如直接使用这样的委托类型:
public delegate bool Spec<T>(T candicate);
当然,您也可以直接使用Func<T, bool>。我在这里创建Spec的目的,是因为我想“明确”这里其实是一个Specification,而不是一个普通的“接受T作为参数,返回bool的方法”。于是现在,我们便可以用这样的扩展方法来编写And,Or和Not:
public static class SpecExtensions { public static Spec<T> And<T>(this Spec<T> one, Spec<T> other) { return candidate => one(candidate) && other(candidate); } public static Spec<T> Or<T>(this Spec<T> one, Spec<T> other) { return candidate => one(candidate) || other(candidate); } public static Spec<T> Not<T>(this Spec<T> one) { return candidate => !one(candidate); } }
用它来编写上次的示例便容易多了:
static Spec<int> MorePredicate(Spec<int> original) { return original.Or(i => i > 0); } static void Main(string[] args) { var array = Enumerable.Range(-5, 10).ToArray(); var oddSpec = new Spec<int>(i => i % 2 == 1); var oddAndPositiveSpec = MorePredicate(oddSpec); foreach (var item in array.Where(i => oddAndPositiveSpec(i))) { Console.WriteLine(item); } }
由于有C#的扩展方法和委托,在C#中使用Specification模式比之前要容易许多。不过,在某些时候,我们可能还是需要老老实实按照标准来做。创建独立的Specification对象的好处是在一个单独的地方内聚地封装了一段逻辑,因此适合较集中,较“重”的逻辑,而“委托”则适合轻便的实现。委托的另一个优势是使用方便,但它的缺点便是难以“静态表示”。如果您在使用Specification模式时,需要根据外部配置来决定进行何种组装,那么可能只有为每种逻辑创建独立的Specification对象了。此外,使用委托还有一个“小缺点”,即它可能会“不自觉”地提升对象的生命周期,可能会形成一些延迟方面的陷阱。
当然,我并不是说独立Specification对象就不会造成生命周期延长——只要功能实现一样,各方面也应该是相同的。只不过独立的Specificaiton对象给人一种“正式”而“隆重”的感觉,容易让人警觉,因而缓解了这方面问题。
不过还有一个问题我们还没有解决——我们现在组装的是委托或Specification对象,但如果我们需要组装一个表达式树,组装完毕后交给如LINQ to SQL使用,又该怎么做呢?我们的“下”便会设法解决这个问题。
韩信点兵 就看到个大旗