Perché non si consiglia di avere una proprietà set-only?

Penso che possa avere a che fare con le aspettative. Le proprietà set-only non sono comuni e le proprietà vengono generalmente utilizzate per set "stupidi" solo per memorizzare un valore senza molta elaborazione. Se stai facendo molto lavoro in un setter, è meglio usare un metodo - le persone si aspettano che i metodi richiedano molto tempo per essere eseguiti e potenzialmente abbiano effetti collaterali. Implementare un tipo simile di comportamento in una proprietà può comportare un codice che viola le aspettative.

Ecco una sezione pertinente di Linee guida per l'utilizzo delle proprietà di Microsoft :

Properties vs. Methods

Class library designers often must decide between implementing a class member as a property or a method. In general, methods represent actions and properties represent data. Use the following guidelines to help you choose between these options.

• Use a property when the member is a logical data member. In the following member declarations, Name is a property because it is a logical member of the class.

public string Name
{
    get 
    {
        return name;
    }
    set 
    {
        name = value;
    }
}

Use a method when:

• The operation is a conversion, such as Object.ToString.
• The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
• Obtaining a property value using the get accessor would have an observable side effect.
• Calling the member twice in succession produces different results.
• The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
• The member is static but returns a value that can be changed.
• The member returns an array. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code. In the following code example, each call to the Methods property creates a copy of the array. As a result, 2^n+1 copies of the array will be created in the following loop.

Type type = // Get a type.
for (int i = 0; i < type.Methods.Length; i++)
{
   if (type.Methods[i].Name.Equals ("text"))
   {
      // Perform some operation.
   }
}

[...skipped longer example...]

Read-Only and Write-Only Properties

You should use a read-only property when the user cannot change the property's logical data member. Do not use write-only properties.

Perché semplicemente non ha senso nella maggior parte dei casi. Quale proprietà potresti avere che puoi impostare ma non leggere?

Se OO è pensato per rappresentare al meglio il mondo reale, è probabile che una proprietà solo dell'insieme suggerisca che la tua modellazione è piuttosto scadente.

Modifica : consulta anche: link che in sostanza dice che non è intuitivo e una proprietà set only è fondamentalmente un metodo con un altro nome, quindi dovresti usare un metodo.

Bene, immagino che se puoi impostare una proprietà su qualcosa ma non la ottieni mai, non saprai mai se qualcos'altro cambia / sovrascrive il valore che hai impostato. Questo potrebbe essere un problema se ti affidi al valore che imposti e non sei in grado (per qualche motivo) di persistere fino al momento in cui vorresti ottenerlo.

L'utilizzo di un metodo anziché di una proprietà di sola impostazione genera un po 'meno confusione per un utente. Il nome del metodo indica solitamente set - o get - , ma i nomi delle proprietà normalmente non indicano che qualcosa può solo essere impostato e non essere ottenuto. Suppongo che se la proprietà fosse qualcosa come "ReadOnlyBackgroundColour" non sarebbe confuso con altri codificatori, ma sarebbe semplicemente strano.