Question

I came across an interface recently that only defined a setter like so:

public interface IAggregationView
{
   DataTable SetSiteData { set; }
}

I queried this, and it is believed that this is one of the practices advocated by Microsoft for WebPart design (for SharePoint). In fact this example is directly copied from their examples.

I see this as a bad pattern, I don’t see why someone should be able to set a value, and then not be able to read it again, and I believe a setter should always be accompanied with a getter (but not necessarily the other way around).

I’m wondering if anyone can explain the benefit of only having a setter, why Microsoft might be suggesting it in this case, and if it’s really a good pattern to be following?

Answer 1

There are two scenarios I can see where this might be reasonable:

1. it is not possible get the value, for example a password; however, I would replace that with a void SetPassword(string) method, personally
2. the API it is designed for has no requirement to ever read the value, and it is being restricted purely to expose the minimum required API

Re my first point, a Set... method may not be ideal if the consuming API is essentially an automated mapper that assigns values to properties; in that scenario properties would indeed be preferable.

Re your “I don’t see why someone should be able to set a value, and then not be able to read it again” – by the same point, however, it could be argued that someone setting the value already knows the value (they set it), so they have no requirement to do this.

But yes; it is very unusual to have a set-only property.