优雅对象实践：将LINQ查询封装为IEnumerable<>实现类是否符合OOD？

关于你的OOD理解是否正确 #

从Yegor Bugayenko倡导的纯面向对象设计理念（反对静态工具方法、将行为封装为一等公民对象）来看，你的理解是完全正确的：你提供的类实现确实比静态LINQ方法更符合OOD的核心原则，将「过滤后的实体集合」作为一个独立的域对象而非方法返回值处理。

当前OOP实现的弊端 #

你给出的FilteredEntities实现确实保留了OOD的优势，但也存在几个明显的问题：

• 冗余代码过多：每新增一种过滤规则，都要完整实现一遍IEnumerable<T>的两个GetEnumerator方法，维护成本会随规则数量线性上升
• 灵活性不足：当前实现的过滤条件硬编码在类内部，无法动态传入过滤参数，也没法和其他过滤规则组合使用
• 存在性能隐患：如果后续扩展时不小心在构造函数中触发了IEnumerable的枚举，会破坏LINQ默认的惰性求值特性，导致不必要的多次遍历
• 语义模糊：FilteredEntities的定义更偏向「过滤规则的执行结果」，而非可复用的过滤逻辑本身，扩展边界不清晰

三个维度的对比 #

可读性 #

• 简单场景下函数式实现完胜：仅需一行代码，逻辑一目了然，没有额外的理解成本
• 复杂业务规则、高频复用场景下OOP实现更优：调用方只需看到类名就能明确集合的业务含义，不需要关心内部的过滤细节

复用性 #

• OOP实现优势明显：过滤逻辑和域对象绑定，可直接在整个业务层传递、继承扩展，不需要每次手动调用过滤方法
• 静态函数式实现的复用强依赖调用方主动调用，一旦过滤规则调整，所有调用点都需要同步适配

可测试性 #

• OOP实现远优于静态方法：你可以将FilteredEntities作为依赖注入到其他类中，单元测试时可以轻松mock返回值，也可以单独为过滤逻辑编写测试用例
• 静态方法属于强依赖，除非使用第三方隔离框架，否则无法在单元测试中实现解耦

更优的替代方案：规约模式 #

你提到的规约模式刚好可以解决当前OOP实现的所有弊端，同时保留OOD和函数式写法的优势，.NET生态下的典型实现如下：

// 通用规约接口
public interface ISpecification<T>
{
    bool IsSatisfiedBy(T entity);
}

// 业务规则：实体字段匹配规约
public class EntityFieldMatchesSpec : ISpecification<Entity>
{
    private readonly object _expectedValue;
    public EntityFieldMatchesSpec(object expectedValue) => _expectedValue = expectedValue;

    public bool IsSatisfiedBy(Entity entity) => entity.Field == _expectedValue;
}

// 扩展方法兼容LINQ原生用法
public static class SpecExtensions
{
    public static IEnumerable<T> Where<T>(this IEnumerable<T> source, ISpecification<T> spec)
        => source.Where(spec.IsSatisfiedBy);
}

调用方式和原生LINQ完全一致：

var filterSpec = new EntityFieldMatchesSpec(targetValue);
var filteredEntities = entities.Where(filterSpec);

这个方案的优势非常明显：

• 每个业务规则都是独立的类，可单独测试、注入、复用，完全符合OOD原则
• 调用写法和原生LINQ一样简洁，没有冗余的模板代码
• 支持多规则组合（与、或、非逻辑），可实现任意复杂的业务过滤需求
• 完全兼容LINQ的惰性求值特性，没有额外性能损耗

使用建议 #

• 如果是仅用1-2次的简单过滤逻辑，直接用静态LINQ写法即可，不需要过度设计
• 如果是核心业务规则、需要复用或频繁调整，优先选用规约模式
• 你原来的IEnumerable实现方式仅适合过滤后的集合本身需要附加额外业务方法的场景（比如批量更新、统计等），否则没有必要编写大量冗余模板代码

内容的提问来源于stack exchange，提问作者danylo.dudok