我的项目中有一个类，用于存储List＆lt;＆gt;元素。我试图弄清楚是否应该允许用户直接添加到该列表（例如，调用本机添加/删除方法）或通过声明List私有来锁定它，并且只允许我选择实际更改的一些方法清单。
这是一个框架，所以我试图尽可能强大地设计它，但我也希望尽可能保持简单和无错误。
在这种情况下，最佳做法是什么？
谢谢， 泰勒
答案 0 :(得分：2)
对于框架，我建议完全封装列表并创建检索和添加元素的方法。
如果需要检查添加的元素，或者某些操作需要触发事件，您将能够这样做。
如果您希望以任何理由不同地存储这些元素，则可以。
另一方面。如果您允许直接访问列表，则很难返回并封装它，或者更改它并使用其他内容。使用此框架的代码可能完全取决于对列表的直接访问。
答案 1 :(得分：1)
保持列表私密性可以让您获得更多控制权并可以使其更加健壮（您可以在将值接受到列表之前检查值）
但保持公开是最简单的。
答案 2 :(得分：1)
这实际上取决于你在做什么。
就个人而言，当我在自定义类中有一个列表，并且它提供了一个数据绑定控件的业务实体列表时，我会将其设为私有并公开一些简单的公共方法来更新它，我可以在那里放置额外的代码，比如移动数据或其他什么。
但是，如果列表是某个查询的结果，那么公开整个事情可能会更好，并且能够使用所有扩展方法等来处理它。
在我看来，关于框架的最新情况是什么
答案 3 :(得分：1)
您应始终将变量保密。有关详细信息，请参阅Jon Skeets advice。基本上是因为您希望控制如何处理数据。用户不需要知道它是List还是其他东西。
如果您使用的是.NET 3.5或更高版本，则可以私下使用List＆lt;＆gt;并创建一个公共属性ReadonlyCollection。这也是线程安全的，但可能需要你做一些工作。
对于这类问题，我可以推荐FxCop。它分析您的代码并为您提供有关设计，性能等的提示。
答案 4 :(得分：0)
您可以对List进行子类化并覆盖修改列表内容的方法。在覆盖中，您可以执行其他处理以防止修改列表，也可以触发事件，以便在列表更改时通知您。如果你想完全禁用该方法，你甚至可以不在覆盖中调用基本实现，并抛出NotSupportedException。
答案 5 :(得分：0)
@Dylan Vester：因为你应该支持组合而不是继承，所以不要继承列表。您可能希望稍后将其更改为其他数据结构，或者在添加到列表之前执行某种验证/检查。