Question

在开发我的应用程序时，我有时会说我需要一个当前的属性，比如私有，但是稍后我们需要处理新的场景时，我们可能需要制作它，比如说公开。但是，即使这种情况即将发生，我也总是希望这个二传手保持私密。我想写这样的代码：

private int A
{
  get{return _a;}
  private set {_a = value;}
}

编译器抱怨setter上的访问修饰符应该比属性更具限制性。好吧，我需要删除set上的访问修饰符，但如果以后我需要将该属性提升为public，我也会公开它的setter。

你认为这不是一个警告而不是错误吗？

Answer 1

如果您要将代码更改为public，则还可以将代码同时更改为private set。

至于这是一个警告，我可以看出它有一定意义 - 我认为只有指定private两次才会有效（尽管它显然毫无意义）。也就是说，我很少遇到这个编译器错误，当我这么做时，我花了5秒钟来修复它并继续前进。

_{具有讽刺意味的是，我们这两个人现在在这个问题和答案上的花费时间都比我们可能曾经对这个错误和它的影响更长： - ）}

Answer 2

你认为这不是一个警告而不是错误吗？

不，我认为您最好使用私有变量（private int _a;），并且仅在需要时将其提升为具有相应修饰符的属性。

当然，如果没有setter，你就不能使用这样的验证：

private int _a;
public int A
{
    get { return _a; }
    private set { 

        if (value < 0 || value > 10)
        {
            throw new ArgumentOutOfRangeException("A");
        }

        _a = value; 
    }
}

但另一方面，首先将物业标记为公众并没有什么坏处，是吗？

Answer 3

更改两个修饰符是完全有效的，所以我不会打扰私有设置器：

public int A
{
  get{return _a;}
  private set {_a = value;}
}

这只是我的 guess ，警告来自编译器将属性重写为IL代码的方式。这些属性将被编写为每个getter和setter方法，其具有与属性本身相同的修饰符。

如果您现在尝试定义私有属性的私有setter，则会转换为：

private private get_A()
{
   return _a;
}

这个加倍的私有修饰符显然不会编译。

Answer 4

您示例中的代码没有意义。如果您的房产是私人的，那么二人也是私人的。如果setter必须有另一个访问修饰符，那么你只需要在setter上指定访问修饰符。

Answer 5

我认为你想要做以下事情......

private int _a;
public int A
{
    get { return _a; }
    private set { _a = value; }
}

这使get访问者公开但设置为私有。

为什么属性访问器中的访问修饰符应该比属性本身更具限制性？

5 个答案: