Specification项目优化：移除Specification中的Evaluator与Validator状态

背景与问题分析

在Specification项目的架构设计中，最初为了提供高度灵活性，允许用户通过构造函数注入自定义的IInMemorySpecificationEvaluator和ISpecificationValidator实现。这种设计虽然在理论上提供了扩展性，但在实际应用中却带来了不必要的性能开销。

经过项目团队的长期观察发现，95%以上的用户并没有真正利用这种扩展能力。大多数用户直接使用库提供的默认实现，却因为这种"以防万一"的设计而承担了额外的内存分配成本——每个Specification实例都需要存储这些实现引用，导致每个实例浪费16字节的内存空间。

解决方案设计

在项目v9版本的性能优化主题下，团队决定对这部分设计进行重构：

1. 移除构造函数注入：不再允许通过构造函数参数传入自定义的Evaluator和Validator实现
2. 改为计算属性：将Evaluator和Validator定义为虚拟计算属性(virtual properties)
3. 保持扩展性：虽然改变了实现方式，但通过保留virtual关键字，仍然允许用户在必要时通过继承覆盖这些属性

这种改变带来了显著的内存优化效果。由于默认实现都是单例实例，访问这些属性时不会产生额外的内存分配。对于绝大多数不需要自定义实现的用户来说，这直接减少了每个Specification实例的内存占用。

技术实现细节

在具体实现上，新的设计将类似以下代码：

public virtual IInMemorySpecificationEvaluator Evaluator 
    => InMemorySpecificationEvaluator.Default;

public virtual ISpecificationValidator Validator 
    => SpecificationValidator.Default;

而不是原来的：

public Specification(IInMemorySpecificationEvaluator evaluator, ISpecificationValidator validator)
{
    _evaluator = evaluator ?? InMemorySpecificationEvaluator.Default;
    _validator = validator ?? SpecificationValidator.Default;
}

兼容性考虑

虽然这是一个破坏性变更(breaking change)，但团队经过评估认为影响范围有限：

1. 普通用户不受影响：继续使用默认实现的用户无需任何代码修改
2. 高级用户小改动：需要使用自定义实现的用户需要改为通过继承覆盖属性，而不是构造函数注入

这种改变符合.NET生态中常见的扩展模式，许多框架都采用类似的设计（如ASP.NET Core中的各种Options配置）。

性能收益

通过这一优化，每个Specification实例减少了：

• 两个引用类型字段的存储（通常各8字节）
• 构造函数参数传递的开销
• 空值检查的逻辑

对于大规模使用Specification模式的应用程序，这种微优化在聚合后可能带来显著的内存节省。

最佳实践建议

对于需要自定义行为的用户，新的推荐做法是：

public class CustomSpecification : Specification<Entity>
{
    public override IInMemorySpecificationEvaluator Evaluator 
        => CustomEvaluator.Instance;
    
    // 其他Specification实现...
}

这种模式更符合SOLID原则，特别是开闭原则(OCP)——通过继承而不是修改来扩展行为。

总结

Specification项目的这一变更体现了软件设计中一个重要的平衡艺术：在提供足够扩展性的同时，不应该让大多数用户为少数人可能用到的功能付出代价。通过将昂贵的"以防万一"设计转变为更轻量的"按需扩展"模式，项目在保持灵活性的同时提升了基础性能，这是框架类库演进的一个典范案例。