Question

虽然我当然熟悉自动属性，但我只是在工作中遇到过这个问题，这似乎是一个截然不同的野兽：

public SomeType SomeProp
{
  get
  {
    return someField;
  }
  set
  {
  }
}

我很惊讶它甚至编译了，我想它一定是个bug：该属性似乎允许设置，但这样做绝对没有。

这个结构有用吗？电梯中的那些“关门”按钮是不是做了什么，但让用户感觉良好？

Answer 1

为什么你不期望它不编译？有效地，setter只是一个带有单个参数的void方法。您可以非常轻松地编写损坏的方法，而不需要编译器注意到 - 属性也是如此。

然而，除了“部分”实施之外，我无法想象任何情况下这是故意的 - 例如演示语言功能，或者如果您正在测试设置属性的内容，但您不关心测试将其设置为什么。（我个人仍然通常至少记录该财产已被设置。）

Answer 2

当需要在Web服务中或使用XML或二进制序列化程序序列化结果时，您经常会看到这种情况。

这是懒惰和邋,,但它经常发生。这使对象具有属性可设置的“外观”。如果它是为了实现一个接口并允许编译，那么执行它的开发人员需要被一个直接的对象殴打头部和肩膀，因为他刚刚打破了界面。如果存在无法实现的正当理由，则开发人员需要将其重新提交给架构师进行审核。实现接口时，不要只留下空的存根方法。如果您目前没有为实现定义的技术，那么至少抛出一个新的NotImplementedException，以便单元测试能够捕获它。

就序列化而言：ReadOnly属性不包含在常规序列化中，这可能使该属性对Web服务客户端不可用。（参考：Read-Only Properties Cannot Be Exposed by XML Web Services。）这是我们都应该转向WCF和DataContracts的原因之一。如果您通过WCF接受此类作为方法的输入类型，则再次检索钝器。

Answer 3

这本身似乎没什么用，但是考虑一个需要类有SomeProp的接口，你需要在类中实现这个接口，但SomeProp只能读取而且不可写。< / p>

public interface IQuestion
{
    public int AnwserToLife { get; set; } //leave out 'set' for read-only
}

public class HitchHiker : IQuestion
{
    public int AnwserToLife
    {
        get
        {
            return 42;
        }
        set
        {  
            //never changes
        }
    }
}

Answer 4

有一些用例，这将是一个必要的解决方法，其中一些我已经“在野外”遇到过。

例如：该物业是旧时的遗骸，不再使用，但该应用程序的其他部分从未更新过（来源丢失？第三方？）并坚持设置该物业。我已经看到，在旧代码中，需要插件在更新某些数据集后设置isDirty属性，当实现更改为观察自身的数据集时，isDirty属性变得无用，但无法放弃，因为其他代码仍然想要设置它。

Answer 5

我建议避免这种编程。它编译，因为它没有理由不应该，但如果接口要求你实现一个setter方法，那么有两个选项：

设置器是冗余的，属性应该是只读的，或
您的代码中有一部分会设置此值，并错误地假设它有效。

具有空访问者的属性

5 个答案: