Propiedad o método WriteOnly?

Question

¿Existe un escenario particular en el que una propiedad WriteOnly tenga más sentido que un método? El enfoque de método se siente mucho más natural para mí.

¿Cuál es el enfoque correcto?

utilización de las propiedades:

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

utilizando métodos:

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

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

EDITAR Solo para aclarar Me refiero a las propiedades "WriteOnly".

Answer 1

Creo que una propiedad indica algo que puede ser de solo lectura o de lectura/escritura. El comportamiento de una propiedad de solo escritura no es obvio, así que evito crearlos.

A modo de ejemplo, el establecimiento de una lista de valores en un desplegable en una vista y acceso al elemento seleccionado:

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

    string SelectedWidget { get; set; } 
} 

tiene más sentido que:

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

    string SelectedWidget { get; set; } 
} 

Answer 2

Por lo que vale la pena , las Directrices de diseño de Microsoft Framework (tal como se plasman en su herramienta FxCop) desalientan las propiedades de solo escritura y señalan su presencia como un problema de diseño de la API, debido a la falta de intuición de ese enfoque.

Answer 3

Dudo que haya una opción correcta. Es una cuestión de gusto.

En ambos casos, pierde algo de encapsulado. Un desarrollador que usa el método o la propiedad necesita saber algo sobre la implementación interna para comprender el resultado. Por eso, los evitaría siempre que fuera posible y, de otro modo, los usaría con moderación.

Para mí, las propiedades sugieren un enlace cercano a un miembro privado con posibles reglas de acceso. Si sólo va a montar un elemento privado y seguro, que haría uso de una propiedad:

public string Password { set; } 

Si sus efectos establecidos varios miembros, me gustaría ir con el método. Algo como:

public void SetToRunMode(object[] runvars); 

Lo más importante es la consistencia.

Answer 4

Estoy de acuerdo con su corazonada: use los métodos. Como puede ver en algunas de estas respuestas, la idea de las propiedades de solo escritura es algo extraño. SetInternalDataProperty() es mucho más fácil de entender y, en última instancia, se trata de qué enfoque causará la menor confusión. Yo iría con tu instinto.

Answer 5

Sin embargo, he visto el.Net Framework en sí utilizar las propiedades de sólo lectura, el primero que viene a la mente es:

System.Net.Mail.MailMessage.To 

para el que tenga que llamar a un método para escribir a:

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

Answer 6

Sólo otro pensamiento:
Una propiedad se supone que siente y prueba lo mismo que un campo. No hay forma de que pueda crear un campo que sea WriteOnly. ReadWrite es posible, ReadOnly (const) es posible, pero no WriteOnly. La inconsistencia es malo [tm]

Answer 7

Aquí es un ejemplo de código que se han utilizado en un proyecto XNA. Como puede ver, Escala es de solo escritura, es útil y (razonablemente) intuitiva y una propiedad de lectura (obtener) no tendría sentido. Claro que podría reemplazarse con un método, pero me gusta la sintaxis.

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

De acuerdo con la regla de análisis de código CA1044:

Get descriptores de acceso proporcionan acceso de lectura a una propiedad y establecer métodos de acceso proporcionan acceso de escritura.

Las pautas de diseño prohíben el uso de propiedades de solo escritura. Esto se debe a que dejar que un usuario establezca un valor y luego evitar que el usuario vea el valor no proporciona ninguna seguridad. Además, sin acceso de lectura, el estado de los objetos compartidos no se puede ver, lo que limita su utilidad.

agregue un acceso directo a la propiedad.

Alternativamente, si el comportamiento de una propiedad de solo escritura es necesario, considere convertir esta propiedad en un método.

Consulte http://msdn.microsoft.com/en-us/library/ms182165.aspx para más detalles