你应该在课堂上使用访客属性，还是只能在课堂外使用？我有一个“数据”类，它使用吸气剂来访问某个数组。如果数组为空，那么我希望数据访问文件、填充数组，然后返回特定值。现在这是我的问题：在创建getter和setter时，您是否也应该使用相同的访问器属性作为访问该数组的方式（在本例中）？还是应该直接访问数组？我在类中使用访问器的问题是，当调用类在Data.array中查找一些信息时，我得到一个无限循环，getter发现数组为null，因此从文件中获取它，然后函数最终再次从Data中获取getter被调用，数组再次为null，我们陷入了无限循环。编辑：那么对此没有官方立场吗？我看到了不使用文件访问访问器的智慧，但是你们中的一些人总是说在类中使用访问器，而另一些人则说永远不要在类中使用访问器………………………………..我同意krosenvold和想概括一下他的建议：不要将属性getter和setter用于读取文件或访问网络等昂贵的操作。对显式昂贵的操作使用显式函数调用。通常，该类的用户不会期望简单的属性检索或分配会花费很多时间。Microsoft的框架设计指南中也推荐这样做。;在以下情况下使用方法而不是属性。该操作比字段集慢几个数量级。如果您甚至考虑提供该操作的异步版本以避免阻塞线程，那么该操作很可能过于昂贵而不能成为一个属性。特别是，访问网络或文件系统（初始化一次除外）的操作最有可能是方法，而不是属性。我认为始终使用访问器是个好主意。然后，如果在获取或设置属性时需要任何特殊逻辑，您就会知道一切都在执行该逻辑。您可以发布其中一个属性的getter和setter吗？也许我们可以帮助调试它。我写了一个getter来打开文件，后来总是后悔。现在，我永远不会通过延迟构建来解决这个问题。吸气剂有副作用，人们不希望吸气剂背后发生各种疯狂的活动。此外，您可能必须确保线程安全，这可能会进一步污染此代码。每次执行此操作时，单元测试也会变得稍微困难??一些。显式构造是比各种惰性初始getter更好的解决方案。这可能是因为我使用的是一个DI框架，它把所有这些都作为标准使用模式的一部分。我真的尽量让构造逻辑尽可能清晰，没有隐藏太多，这样代码更容易理解。不，我认为你不应该这样做，原因是：可维护的代码。我见过人们在定义类时使用属性，一开始看起来很不错。然后其他人出现并添加了属性的功能，然后其他人出现并试图更改类，他们不完全理解类，一切都乱套了。这不应该，因为维护团队应该完全了解他们想要更改的内容，但他们经常查看不同的问题或错误，并且封装的属性经常会逃避他们。我见过很多，所以永远不要在内部使用属性。它们也可能会影响性能，如果有人将数据库代码放入属性中，简单的查找会变得很烦人——我也见过有人这样做！这么多年过去了，KISS原则仍然有效……！除了其他人提出的观点之外，是否直接使用访问者或字段可能需要通过语义来告知。有时，访问属性的外部消费者的语义不同于通过内部代码访问其值的机械必要性。EricLippert最近在多篇文章中发表了关于此主题的博文：自动与显式属性Future-Adopting-A-Design如果使用Get方法导致此类错误，则应直接访问该值。否则，最好使用您的访客。如果您应该修改getter或setter以在将来执行特定操作，那么如果您未能使用该路径，您的对象将被销毁。我认为您要实现的是某种延迟加载属性，其中数据仅在第一次访问时加载。在这种情况下，我会使用以下内容来防止无限循环：privateMyData_data=null;publicMyDataData{get{if(_data==null)_data=LoadDataFromFile();返回数据；}}privateMyDataLoadDataFromFile(){//...}换句话说：你应该总是使用访问器，但你应该只调用从文件中读取值的函数（应该是私有的并调用像getValueFromFile这样的函数），并且应该只读取文件并返回值。该函数在另一个类中甚至可能更好，专门用于从数据文件中读取值。如果我理解正确，您正试图从其实现访问属性（通过使用在属性的实现代码中调用相同属性的方法）。我不确定这是否有任何官方标准，但我认为这是不好的做法，除非有特定需要这样做。我总是喜欢在类中使用私有成员而不是属性，除非我需要提供函数属性实现。以上是C#学习教程：应该在类中使用visitor属性，还是只能在类外使用？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
