Interface: Setter without a Getter

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.

Answer 2

The role of get and set in interface properties is slightly different from those in classes.

public interface IAggregationView
{
   DataTable SetSiteData { set; }
}

class AggregationViewImp : IAggregationView
{
   public DataTable SetSiteData { get; set; }  // perfectly OK
}

The interface specifies that the property should at least have a public setter. The definition and accessibility of the getter is left to the implementing class.

So if the interface contract only needs to write, get can be left open. No need to demand a public getter.

As a consequence, you cannot really specify a read-only property in interfaces either. Only 'at least read access'.

interface IFoo
{
    int Id { get;  }
}

class Foo : IFoo
{
    public int Id { get; set; }  // protected/private set is OK too
}

Answer 3

I can imagine using it for (manual) dependency injection. A class may need to have a collaborator injected that it only uses internally. Of course one would normally choose to do this in the class' constructor, but there may be times when one would wish to change the collaborator at runtime.