write only properties

I am just curious about this, but in all my years writing code, I have never once ever come across a time to use a write only property. Of course readonly is pretty common in class development, and while I may have had classes where I don't specifically need to expose a property for reading, generally you end up with a method like SetValue or something like that, which is more or less the same idea as a writeonly property.

I don't recall ever seeing a writeonly property in a .NET framework class.


So can anyone provide an example where it actually made good sense to use a writeonly property over either a read/write property, or a method?

I recently wrapped a Form with another class for the purpose of reducing the number of user properties to something like 8 or so instead of all of a Forms properties; it was a special top level control. The wrapping class (outer) exposed the Getter and Setters. It was only required that the wrapped Form (inner class) have Setters. Originally it had both Getters and Setters until I ran FxCop which informed me that there were no upstream calls to the Getters. That, of course, was true; so I removed the Getters which were being provided to the user via the wrapper class.

EDIT: I just realized you said Properties.

Well, when I'm initializing a class, I want to set a few variables, so I create a WriteOnly Property that I call, though I suppose a regular call would work just fine.

I guess that won't make complete sense until I mention that I shadowed some of the Form properties and my only reason for not adding methods in the wrapped class was because they were in fact properties and not actions or calculations.

A couple of interesting notes from VS 2010 documentation:

First the reason:
"Sometimes you want the consuming code to be able to set a value but not discover what it is. For example, sensitive data, such as a social registration number or a password, needs to be protected from access by any component that did not set it. In these cases, you can use a WriteOnly property to set the value."

Then some notes:
Additional protective measures:Overriding. If the property is a member of a class, allow it to default to NotOverridable (Visual Basic), and do not declare it Overridable or MustOverride. This prevents a derived class from making undesired access through an override.

Access Level. If you hold the property's sensitive data in one or more variables, declare them Private (Visual Basic) so that no other code can access them.

Encryption. Store all sensitive data in encrypted form rather than in plain text. If malicious code somehow gains access to that area of memory, it is more difficult to make use of the data. Encryption is also useful if it is necessary to serialize the sensitive data.

Resetting. When the class, structure, or module defining the property is being terminated, reset the sensitive data to default values or to other meaningless values. This gives extra protection when that area of memory is freed for general access.

Persistence. Do not persist any sensitive data, for example on disk, if you can avoid it. Also, do not write any sensitive data to the Clipboard.

On top of the notes above, FxCop seems to want to get rid of any sort of unused code. One form of which is uncalled Getters -- At least for class libraries.

I had a class where the data being fed into it came from multiple properties. I didn't need to read them back (they were combined into a single data element), so it didn't make sense to make them readable properties... so they are write only.

-tg

This is a very old piece of Wrox code where it made sense to have a write-only property.

VB Code:

Imports System
Imports System.Xml
 
Public Class AppSettingsWriter
    Private configFileName As String
    Private document As XmlDocument
 
    Public Sub New()
        Dim asmy As System.Reflection.Assembly
        Dim tempName As String
 
        asmy = System.Reflection.Assembly.GetEntryAssembly()
        tempName = asmy.Location
 
        configFileName = tempName & ".config"
 
        document = New XmlDocument()
        document.Load(configFileName)
    End Sub
 
    Default Public WriteOnly Property Value(ByVal key As String) _
    As String
 
        Set(ByVal Value As String)
            Dim Query As String
            Dim Node As XmlNode
            Dim Root As XmlNode
            Dim Attribute1 As XmlNode
            Dim Attribute2 As XmlNode
 
            Query = "/configuration/appSettings/add[@key=" & _
                Chr(34) & key & Chr(34) & "]"
            Node = document.DocumentElement.SelectSingleNode(Query)
 
            If Not Node Is Nothing Then
                Node.Attributes.GetNamedItem("value").Value = Value
            Else
                Node = document.CreateNode(XmlNodeType.Element, "add", "")
 
                Attribute1 = document.CreateNode(XmlNodeType.Attribute, _
                    "key", "")
                Attribute1.Value = key
                Node.Attributes.SetNamedItem(Attribute1)
 
                Attribute2 = document.CreateNode(XmlNodeType.Attribute, _
                    "value", "")
                Attribute2.Value = Value
                Node.Attributes.SetNamedItem(Attribute2)
 
                Query = "/configuration/appSettings"
                Root = document.DocumentElement.SelectSingleNode(Query)
 
                If Not Root Is Nothing Then
                    Root.AppendChild(Node)
                Else
                    Throw New InvalidOperationException( _
                        "Could not add node to config file")
                End If
            End If
        End Set
    End Property
 
    Public Sub SaveFile()
        document.Save(configFileName)
    End Sub
End Class

In theory a writeonly property would make sense if prior knowledge of the value of the property wasn't allowed.

BID - Multics was one of the most secure operating systems I ever worked on. One of the principles was that you didn't allow bugs to be fixed by modifying the executable, you fixed the source. Executable files normally had Read / Execute permissions, but only because the hardware needed it. If the designers could have had their way the executable would have had only execute permissions and the hardware would have understood the difference between reading for manipulation and reading for execution.

I didn't see anything (with maybe the exception of FourBlades using inheritence and shadowing (and wanting Fx cop compliance)) that REALLY needed to be a writeonly property for a specific reason.

initializing a class by passing values to writeonly properties is the same thing as passing them to a constructor, and the wrox example could have just been a function. Not to say it is a bad example, I was just looking for an example where you HAD to use a writeonly property and using a sub/function or just a read/write property made no sense.

I can see a use for this when creating self-contained security objects that need to be serialised for sending over a network. You could imagine it for example like a treasure chest that's locked from the inside. A method that accepts a password, for example, can cause the object to dump its information where it's meant to go, like a database, but that's it, there is no other way to READ the data. This for example could allow applications and users to handle data, update it, without ever knowing what it is, then updating a database.

I could imagine in the social security department, a worker has some data that needs to be updated about a person. When the person object is retrieved from the database, it is available to her in the form of an input only object. She can make a couple of changes, then call the database update method within the object itself, and the object will dump itself back into the database without exposing anything at all to her application. Not connection strings, database types, data, period.

I think that there is never a need for a write only property. A method would work just as well, and I know of no performance differences of one over the other.

Maybe perhaps if you wanted databinding on the property, otherwise a method would still be better. I don't really get a databound writeonly property since i would imagine that if it were for security purposes it would be more dangerous having sensitive data being written to a property because you don't know when the data will actually persist back to the database. With a method of something like SetSecureValue() that does the write to the database right away and can clean up the sensitive values from memory right away.

As I mentioned in Shaggy's other thread, I never said it was a good example. :rolleyes: Just an example to satisfy the curiousity. It's a damn good question though.

Methods aren't stateful. The write-only property would be. As I mentioned, I had a project where I had 4 data points that were combined to calculate a single result in the end. Problem was that they different data points were calculated in different places at different times. Using variables to shuffle the data around wasn't worth it.... so I created them as Write-Only Properties (once I set them, I didn't need to read them back) on the class they belonged to. Then, when I needed the combined point, I had a read-only property that did the calculations, and returned the end result.

-tg

Methods can SET state in a class though. If you aren't ever going to allow a consumer of the class to read the value of the property, then there is no logic to say the property can provide information on the state of the object.

You could easily have a method called AddDataPoint which accepts a datapoint which is added to an internal collection and processed whenever you want to process it.

My only point here is a writeonly property seems like nothing more than a method to me, with the single exception of a databinding scenario.

I'm not sure whether you care or not but MSDN specifically states that using a WriteOnly property is indicative of a design flaw.

Source

The theory is that, allowing a user to set a value but not allowing them to read it back presents a security issue. I completely agree with this rule.

I'm not even sure about a databinding situation.... what would you bind to? It can't read back the value for displaying... And yes, I probably could have used a Set method... it was easier this way as I was lining up my data points from the file I was reading it from.

-tg

To behonest I don't even know if you can databind to a writeonly property, but my thinking was in a situation where your class was populated with data from a backing datasource, and the value from some column in the database you want for internal class usage, but not for the class consumer to see.

Quote:

---

Originally Posted by ForumAccount

The theory is that, allowing a user to set a value but not allowing them to read it back presents a security issue.

---

Possibly true but how about an external DLL that exposes a password change function, with the new password being a write-only property? Obviously the same can be achieved with a method call, but I'm just arguing here.

So we have some inconsistency from MS.

I'll double check... FxCop warned there were no upstream calls to the Getter.
So I made the properties WriteOnly. FxCop presented no new warnings after that and I still have all of the possible warnings selected.

Given what I've seen here, maybe FxCop should have subsequently suggested to change the WriteOnly properties to Methods.

Or maybe in the original warning they could have injected a little levity --
"And don't even think of making these WriteOnly properties."

Anyway we have post #5 and post #16 presenting conflicting views from MS.

Quote:

---

Originally Posted by ntg

Possibly true but how about an external DLL that exposes a password change function, with the new password being a write-only property? Obviously the same can be achieved with a method call, but I'm just arguing here.

---

I agree that you could possibly find a situation where instead of a method call you use a WriteOnly property, but the Microsoft design guidelines prohibit the use of them. This leads me to believe the preferred/recommended way is via a method call.

Quote:

---

Originally Posted by FourBlades

Anyway we have post #5 and post #16 presenting conflicting views from MS.

---

Hmm... interesting.