Question

是否存在WriteOnly属性比方法更有意义的特定情况？方法方法对我来说更自然。

什么是正确的方法？

使用属性：

Public WriteOnly Property MyProperty As String
   Set(ByVal value as String)
      m_myField = value
   End Set
End Property

public string MyProperty
{
   set{ m_myField = value;}
}

使用方法：

Public Sub SetMyProperty(ByVal value as String)
   m_myField = value
End Sub

public void SetMyProperty(string value)
{
   m_myField = value;
}

修改只是为了澄清我指的是“WriteOnly”属性。

Answer 1

我认为属性表示可以是只读或读/写的东西。只写属性的行为不明显，所以我避免创建它们。

例如，在视图的下拉列表中设置值列表并访问所选项目：

public interface IWidgetSelector
{
  void SetAvailableWidgets(string[] widgets);

  string SelectedWidget { get; set; }
}

比以下更有意义：

public interface IWidgetSelector
{
  string[] AvailableWidgets { set; }

  string SelectedWidget { get; set; }
}

Answer 2

对于它的价值，Microsoft框架设计指南（在其FxCop工具中体现）不鼓励只写属性，并将其作为API设计问题标记，因为该方法不直观。

Answer 3

以下是我在XNA项目中使用的示例代码。正如您所看到的， Scale 是只写的，它很有用且（合理地）直观，并且读取属性（ get ）对它没有意义。当然它可以用方法替换，但我喜欢语法。

public class MyGraphicalObject
      {
      public double ScaleX { get; set; }
      public double ScaleY { get; set; }
      public double ScaleZ { get; set; }

      public double Scale { set { ScaleX = ScaleY = ScaleZ = value; } }

      // more...
      }

Answer 4

另一个想法：
属性应该感觉和品尝与字段相同。你无法创建一个WriteOnly字段。 ReadWrite是可能的，ReadOnly（const）是可能的，但不是WriteOnly。 不一致是不好[tm]

Answer 5

我同意你的预感：使用方法。正如您从其中一些答案中看到的那样，只写属性的想法有点奇怪。 SetInternalDataProperty（）更容易理解 - 最终，这是一个问题，哪种方法会造成最小的混乱。我会选择你的直觉。

Answer 6

我怀疑这是一个正确的选择。这是一个品味问题。

在这两种情况下，您都会失去一些封装。使用方法或属性的开发人员需要了解有关内部实现的内容以了解结果。因此，我会在可能的情况下避免使用它们，否则会谨慎使用它们。

对我而言，Properties建议使用可能的访问规则与私人成员建立密切联系。如果您只是设置一个安全的私人成员，我会使用一个属性：

public string Password { set; }

如果您的设置影响了几个成员，我会选择该方法。类似的东西：

public void SetToRunMode(object[] runvars);

最重要的是一致性。

Answer 7

但是我看到.Net Framework本身使用了ReadOnly Properties，第一个想到的是：

System.Net.Mail.MailMessage.To

您必须调用要写入的方法：

System.Net.Mail.MailMessage.To.Add(Recipient As String)

WriteOnly属性或方法？

8 个答案: