Is there practical application in write-only properties?

Question

In object-oriented programming, a property is a member of a class that provides information about the object. That is, properties expose attributes.

Properties can also be "write only". An example in C#:

public class Program
{
    string _foo;
    public string Foo
    {
        set
        {
            _foo = value;
        }
    }
}

Although the question is language independent, the same is possible in Visual Basic, which still exposes a syntactic sugar for this, and in other languages such as Delphi.

Is there any practical application in properties write-only?

Answer 1

First read this: What is the difference between attribute and field in the classes?.

This indicates that you want to let the consumer assign a value to the object and then not let it move anymore, so whenever you need it can be used.

I don’t like it because usually someone forgot What good is a builder?. But C# has encouraged this a bit in recent versions using property initializer. Not that it has anything to do with not having the getter, I am just showing that the constructor may not be as used as it was before, although some problems may arise if the person does not know how to use it. The builder gives even more guarantees.

There may be some rare cases where the change needs to be made even if the object already exists, even if it is not just an initializer.

Increased security

The most obvious information I can think of is a password. You have reasons to change the password, but have no reason to take its value, including because if the object treats it correctly nor is it possible to pick up what is the actual password because something has been encrypted.

This is a case where the object will use what is on it to authenticate something but this use is only internal (a method that will authenticate), it will not be visible. Preventing access to data after entering the object increases security instead of decreasing.

But this case needs to be done carefully because it involves security, need to see if the object should be keeping a circulating password even if encrypted.

And of course it goes for any information that is not stored the same as what you sent or that should no longer be handled externally.

I always talk, people shouldn’t use getters/setters automatically, have to think when this is useful and when it should only have a more significant method to make an operation with more sense and not know anything about the field, because almost always the property exposes the field, then there is some level of abstraction leak.

There may be some case of an object that must be immutable and that it itself has no reason to take the value (this would be done with another object that would eventually receive the information of that first object, that is, each object has a specific function in the application). I find complication and zeal excessive, but it is possible to have something like this, it is safer for the programmer to have one object only to write and another only to read.

I can’t think of anything practical, but whenever you need to assign a mechanism that happens to be object implementation detail and no one else theme see it so it makes sense, but again, it should have done in the constructor.

Not giving access to value within the object is safer in these cases.

Write-only method instead of property

For what? What is the advantage of this? The property is already a couple of methods and if it does not allow reading it has only one, it will not use the syntax of the method. Just as no one suggests to use method syntax when only has the getter, it doesn’t make sense to do that when you only have the Setter. I’ve seen people suggest it, but in general people don’t know why they’re doing it.

The reason to use method syntax instead of property is if it has a long processing and not just access a state in a simple, though not direct, way. So you know that you are running something that requires processing and "obliges" you to read the documentation to use, while a property you have in mind is just accessing a simple data.

So if it’s a writing property that generates a long processing it makes sense the method, but if it’s something like a password the property is suitable.

We always need to understand the reason for certain rules. And that they have exceptions, good programmer is pragmatic, not dogmatic. With motivation one can make a proper decision instead of blindly following what someone said.

Completion

In fact, it’s not that useful, but language needs to support rare cases where it’s useful, which is why I always say that blindly following cake recipes created by other people is not knowing how to program, "always" has reasons to use something, even if the normal is not to use.

Answer 2

There is some practical application in write-only properties?

I honestly cannot see a really practical application. If you need to set something on some object and will do it only once could use a constructor.

Or if you want to set a value more than once and do not want to have access to this content, you could use a method.

Although it is possible to do this in C# as it is in your example, there is even a rule of code analysis that will generate an alert (or error depending on setting) about using a property write only: https://docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/quality-rules/ca1044

CA1044: Properties should not be write only

Meaning, "Property shouldn’t be write only

The description of the reason for this rule is:

Get accessors provide read access to a Property and set accessors provide write access. Although it is acceptable and often necessary to have a read-only Property, 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.

In free translation:

Get accessors provide read access to a property and Set accessors provide write access. Although it is acceptable and often necessary to have a read-only property, the design guidelines prohibit the use of recording-only properties. This is because it allows a user to define a value and, in then, prevent the user from viewing the value offers no security. In addition, without reading access, the state of the objects shared cannot be viewed, which limits its usefulness.

There are some reasons to avoid using write-only properties. Anyway, the rules of code analysis are optional and only one point to analyze.