问题
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?
Using Properties:
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;}
}
Using Methods:
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.
回答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; }
}
回答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.
回答3:
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...
}
回答4:
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]
回答5:
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.
回答6:
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.
回答7:
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)
回答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
来源:https://stackoverflow.com/questions/322941/writeonly-property-or-method