WriteOnly Property or Method??

Question

Is there a particular scenario where a WriteOnly property makes more sense then a method? The method approach feels much more natural to me. What is the right approach?

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;}
}

VS

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

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

EDIT Just to clarify I am referring to "WriteOnly" properties.

Answer 1

I think a property indicates something that can be read-only or read/write. The behaviour of a write-only property is not obvious so I avoid creating them.

As an example, setting a list of values in a drop-down on a view and accessing the selected item:

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

  string SelectedWidget { get; set; }
}

Makes more sense than:

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

  string SelectedWidget { get; set; }
}

Answer 2

For what it's worth, the Microsoft Framework Design Guidelines (as embodied in their FxCop tool) discourage Write-Only Properties and flag their presence as an API design issue, due to the unintuitiveness of that approach.

Answer 3

I doubt there's a right choice. It's a matter of taste.

In both scenarios you lose some encapsulation. A developer using the method or property needs to know something about the internal implementation to understand the outcome. Because of that, I'd avoid them when possible and otherwise use them sparingly.

To me, Properties suggest a close link to a private member with possible access rules. If you're simply setting a secure private member, I'd use a Property:

public string Password { set; }

If your set effects several members, I'd go with the method. Something like:

public void SetToRunMode(object[] runvars);

The most important thing is consistency.

Answer 4

I agree with your hunch: use methods. As you can see from some of these answers, the idea of write-only properties is sort of weird. SetInternalDataProperty() is much easier to understand -- and ultimately, this is a question of which approach will cause the least confusion. I'd go with your gut.

Answer 5

However I've seen the .Net Framework itself use ReadOnly Properties, the first one that comes to mind is:

System.Net.Mail.MailMessage.To

For which you have to call a method to write to:

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

Answer 6

Just another thought:
A property is supposed to feel and taste the same as a field. There is no way you could create a field that is WriteOnly. ReadWrite is possible, ReadOnly (const) is possible, but not WriteOnly. Inconsistency Is Bad [tm]

Answer 7

Here is an example of code I have used in an XNA project. As you can see, Scale is write-only, it is useful and (reasonably) intuitive and a read property (get) would not make sense for it. Sure it could be replaced with a method, but I like the syntax.

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 8

As per the code analysis rule CA1044:

Get accessors provide read access to a property and set accessors provide write access.

The design guidelines prohibit the use of write-only properties. This is because letting a user set a value and then preventing the user from viewing the value does not provide any security. Also, without read access, the state of shared objects cannot be viewed, which limits their usefulness.

add a get accessor to the property.

Alternatively, if the behavior of a write-only property is necessary, consider converting this property to a method.

Please refer http://msdn.microsoft.com/en-us/library/ms182165.aspx for more details