Are set-only properties bad practice?

Question

I have some C# code that loves to create properties that have setters but no getters. To me this seems like an anti-pattern, but am I missing something?

public List<SiteVisitSummary> DataSource {
    set {
        // crazy logic here 
    }
}

Answer 1

I don't know if I'd call it an anti-pattern or not. I think the important thing to realize is that the property in your example is essentially a method, disguised as a property. For this reason it's unintuitive, and I'd generally avoid it. To me this looks a lot more natural:

public void SetDataSource(IEnumerable<SiteVisitSummary> dataSource)
{
    // crazy logic here
}

One fairly reasonable case I have seen made for set-only properties is when there are several properties grouped together such that setting all to a single value is a reasonable thing to do (but obviously, getting all as one value doesn't make sense). For example:

class Polyhedron
{
    public int Height { get; set; }
    public int Width { get; set; }
    public int Depth { get; set; }

    public int AllDimensions
    {
        set { Height = Width = Depth = value; }
    }
}

Answer 2

It could be useful for Dependency Injection, where instead of using a constructor for the injection you are using properties.

Answer 3

I don't see anything inherently bad about the practice, although it doesn't make much sense to me.

The point of encapsulation is to limit what can change the state of an object so that the state becomes easier to maintain. I can't think of any good reason to make a property write-only. And, if I could, it might more sense to make it a method instead.

Users are accustomed to being able to read properties and they may waste time wondering why the heck your property is so weird.

Answer 4

Not bad practice as such, just not very useful (a property that you can't read?).

Answer 5

If you are expecting much logic to happen, it would seem much clearer of the cost by using a method to set that.

Answer 6

This may not be everyone's cup of tea, but I posted an answer to another question where I demonstrated the use of an "infuser" concept, in this case a struct nested inside of an immutable struct. The infuser has write-only properties that complement the read-only properties of the immutable type.

To be fair, I agree that this approach might be confusing and I would think twice before including code like this in an application that is not just a hobby project.

The concept can also be useful for normal classes, not just immutable types. It allows the code that is responsible for instantiating an object to have read/write access to the data contained within that object. Then the object can be passed off to other code, which has read-only access to the data within the object.

Answer 7

It's kind of a weird thing really. Why would you write an API that allows the user to set a list but not read it? How about returning a ReadOnlyCollection instead and exposing the property as an IList instead of a List?