Write-Only properties, what's the point? [duplicate]

Answer 1

One use for a write-only property is to support setter dependency injection.

Let's say I had a class:

public class WhizbangService {
    public WhizbangProvider Provider { set; private get; }
}

The WhizbangProvider is not intended to be accessed by the outside world. I'd never want to interact with service.Provider, it's too complex. I need a class like WhizbangService to act as a facade. Yet with the setter, I can do something like this:

service.Provider = new FireworksShow();
service.Start();

And the service starts a fireworks display. Or maybe you'd rather see a water and light show:

service.Stop();
service.Provider = new FountainDisplay(new StringOfLights(), 20, UnitOfTime.Seconds);
service.Start();

And so on....

Answer 2

Interesting question.

After some Googling, this is all I could find: a write-only property could be used to set a password on a User object. Since passwords are usually stored in hashed form, there is (and should be) no way to retrieve a password after it has been set.

Answer 3

I have never come across a valid use-case for a write-only property. Honestly, if there is a valid use-case for a write-only property I think it is safe to say that the solution is poorly designed.

If you need "write-only" semantics you should use a method. For instance, another user has found an example of a user object that uses a write-only property to set a password. This is a bad design:

class User
{
    public string Password
    {
        set { /* password encryption here */ }
    }
}

Ugh. This is much better:

class User
{
    public void SetPassword(string password)
    {
        /* password encryption here */
    }
}

See, a read/write property is a set of methods that are designed to masquerade as a field. They look and feel like a field. It is for this reason that a read-only property makes sense because we are used to having fields and variables that we can read but cannot change. However there isn't a corresponding field or variable construct that is writable but not readable.

This is why I believe that creating an API that employs write-only properties is bad practice. It runs counter-intuitive to what I believe is the main goal of the property syntax in C#.

Edit: More philosophy... I believe that classes serve a functional purpose: they provide a container for related data to be held and manipulated. Take our User class for example - this class will hold all pieces of information that pertain to a user in the system. We collect all these pieces of data and give them a single name: user. In this way we use classes to create abstractions. User is an abstraction that allows us to reason about all the individual pieces of data that comprise a user (password, name, birthday, etc.).

Now there are good abstractions and there are bad abstractions. I believe that write-only properties are bad abstractions because you are allowing someone to input data and not read it. Why would you disallow this? Most likely because the information that has been passed in has been transformed in some way that makes it unreadable to the passer.

So this means that a write-only property by definition must create side-effects that the caller cannot see (because if they could see them then there would be no reason to make the property write-only). The best construct in the C# language for setting a value with side-effects is the method.

I would highly recommend not using write-only properties because consumers of your API will find them confusing and frustrating. Even if you find a valid use-case for this syntax it doesn't justify its use.

---

Edit: Here is official recommendation from .Net Framework Design Guidelines for Developing Class Libraries -> Member Design Guidelines -> Property Design

Do not provide set-only properties.

If the property getter cannot be provided, use a method to implement the functionality instead. The method name should begin with Set followed by what would have been the property name...

Answer 4

I'm sure the feature is there simply for symetry with a get-only variable. As Aphex sort of vaguely implies, some things have no point and are only there because it's easier to leave it in than to remove it.

Answer 5

A common case I can see is if you only wanted a caller to be able to obtain a transformed version of your property. For example:

public int MyInt { set; }
public string MyIntAsString 
{ 
   get { return this.MyInt.ToString(); } 
}

Obviously, this isn't a real example, but you get the picture.

EDIT:

After reading Thomas' example use case, then a real "transformation" type scenario could be to retrieve an encrypted version of the write-only property:

private string password;

public string ClearPassword { set { this.password = value; }
public string EncryptedPassword
{
   get { return Encrypt(password); }
}

Answer 6

I have had cause for a write-only property.

In a .NET web-service, I have had to create a legacy ASMX web-service, as the URI is hard coded in hardware.

I'm a big fan of using Ninject for dependency injection, using constructor injection to satisfy all dependencies a class may have. For the most part, these dependencies would be declared private readonly fieldName and assigned to in the constructor. The reason for this is that the dependencies of the class are not part of the class' responsibilities; they are dependencies.

However, the problem is whatever factory mechanism ASP.NET uses to create the class instance for a web-service relies on there being a constructor with no arguments, that scuppered my constructor injection.

I could have used a call from the default constructor to re-direct to an overloaded constructor making use of a ServiceLocator (anti)pattern, but I didn't fancy that.

Using the Ninject web extension, I inherited my service class from Ninject.Web.WebServiceBase and employed property injection, marking the properties that Ninject would satisfy with an [Inject] attribute.

Getting back to the point about injected services being dependencies for the class, rather than responsibilities that the type has, I don't want these dependencies properties accessed by other classes, so I mark the get property as private.