List <t>应该是私有的吗？</t>

Question

我需要你的意见，因为我在这个问题上已经阅读了很多不同的东西。如果您在类声明中有List<T>或任何类型的列表，您是否将其设为私有，然后使用特定方法添加或删除项目，还是将其公开？

每个选项的任何缺点/优点都会使您的观点受到高度赞赏。

举个例子，假设我们有class Employer个私有字段name和List<Employees>。我的问题是，我们是否应该将员工名单列为私人或公开，以及两种情况下的优缺点是什么。

Answer 1

for list明确是的它应该是私有的，这取决于你所暴露的功能应该做什么，IEnuemerable，ICollection或IList等接口将是更好的选择，或者如果你公开了一个集合请参阅SLaks回复。

通常暴露内部结构和状态是一个坏主意，因为您的类型为List的对象都是，所以您希望将其保持在内部。 让用户能够迭代它，添加或删除项目可能是有意义的，但你仍然应该保持List内部并暴露添加/删除方法或至少暴露一个接口使得可以更改不影响公共接口的内部表示的类型。

如果您使用界面进行曝光，则应该选择最窄的界面。

因此，如果客户端代码只需要枚举它。如果客户端代码需要索引使用ICollection等，请使用IEnumerable。

此外，如果您作为IEnumerable公开，您应该确保您返回的内容实际上只能通过使用只读集合类或使用迭代器块来读取

更新后编辑 关于你的例子。问问自己除了雇主以外的任何人都可以改变他的员工是谁，这是否有意义？用你已经选择过的话来对我说。雇主雇用员工，并且应该完全控制他/她的员工。因此，在这种特殊情况下，我会将其保密，并公开Hire（IEmployee员工）和Fire（IEmployee员工），这样代码明确表明了意图

Answer 2

如果您需要向您的班级用户展示一个集合，您应该使用System.Collections.ObjectModel.Collection<T>创建一个只读属性。

然后，您可以继承此类并覆盖InsertItem，RemoveItem和SetItem，以便在用户操作集合时运行自定义逻辑。

如果您不希望用户能够更改集合，则应公开ReadOnlyCollection<T>。

在您的具体示例中，您可能应该在ReadOnlyCollection<Employee>中使用单独的mutator方法公开Employer。

Answer 3

如果您想要的是能够枚举列表，那么您可以公开一个iEnumerable，它的GetEnumerator函数只会调用列表的GetEnumerator函数。

Answer 4

根据重构目录，它总是更好地包围集合。这可以防止某些人通过在列表中添加或删除项目而意外地破坏数据。如果您不需要保护数据免遭意外更改的功能，则可以返回正常列表。

通过公开Add和Remove方法，您可以获得任何更改仅通过这些方法发生的优势。

Answer 5

取决于您想要的功能。如果您只是希望人们能够操作列表，您可以通过只读属性（没有setter）公开它。如果您希望在用户操作列表时执行额外的代码，您应该编写自己的方法，而不是公开列表。