Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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
Re: write only properties
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
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.
Re: write only properties
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.