我有一个类，它有一个IEnumerable。在这个类上有一个接口函数，用于{IE}这个IEnumerable集合的新项目。此接口Add函数的工作方式是首先将当前集合转换为列表，添加新集合，然后将其转换回IEnumerable。现在，IEnumerable的实例已经改变，并且对该类的IEnumerable成员的所有引用都是“解耦的”。
这只是一个选择问题吗？或者是否需要保持IEnumerable引用耦合的行为？
是否有针对此类行为的编码指南？
请参阅下面的示例代码，该代码演示了解耦行为：
Add答案 0 :(得分：3)
你的问题只是一个更普遍问题的一个特例：如果一个对象公开了一个返回类型提供某事物的只读视图的方法，那么返回的视图应该是：
不可变快照的视图，即使对象也不会改变。
对象的“实时”只读视图，将显示对对象所做的任何更改
只要对象未被修改就会反映对象的当前状态的视图，但如果是，则不会对行为做出任何承诺。
在许多情况下，＃3将是提供方法的最便宜的，它将满足大多数呼叫者的需求。调用者不应该期望方法返回＃1或＃2，除非方法的文档明确指定了哪个;为＃3做好准备的来电者将对上述任何一个感到满意。
Java和.NET的创建者如此反对匈牙利符号太糟糕了，因为像上面这样的区别对它来说非常有用。如果方法返回IEnumerable<T>，则类型系统中的任何内容都不会指示它返回上述哪种类型的东西，但在尝试编写高效且正确的代码时，这些信息通常是至关重要的。我建议您肯定地决定是否希望向呼叫者承诺您返回的对象永远不会改变，或者是否明确地避免做出这样的承诺。做出承诺将允许一些调用者更有效（因为想要快照的调用者将能够直接使用返回的对象，而不是必须将内容复制到新的不可变对象），但可能会强制该类的未来版本复制可变对象的内容以便返回它们，否则它只能返回一个只读包装器。