界面:没有Getter的Setter

Question

我最近遇到了一个界面,它只定义了一个像这样的setter:

public interface IAggregationView
{
   DataTable SetSiteData { set; }
}

我质疑这一点,并且相信这是微软为WebPart设计(针对SharePoint)所倡导的做法之一.实际上,这个例子是从他们的例子中直接复制的.

我认为这是一个糟糕的模式,我不明白为什么有人应该能够设置一个值,然后再也无法再读它了,我相信一个二传手应该总是伴随着一个吸气剂(但不一定是其他方式).

我想知道是否有人可以解释只有一个二传手的好处,为什么微软可能会在这种情况下建议它,以及它是否真的是一个好的模式？

Answer 1

我可以看到两种情况,这可能是合理的:

1. 它不是可能获得的价值,例如密码; 但是,我个人会用一种void SetPassword(string)方法取而代之
2. 它所设计的API 无需读取该值,并且仅限于公开所需的最低API

重申我的第一点,如果消费API本质上是一个为属性赋值的自动映射器,那么Set... 方法可能并不理想; 在那种情况下,属性确实更可取.

重新你的"我不明白为什么某人应该能够设置一个值,然后再也无法读取它" - 但同样地,可以说有人设置值已经知道了价值(他们设定了它,所以他们没有要求这样做.

但是,是的; 拥有一个只有一个属性的属性是非常罕见的.

Answer 2

接口属性get和set在接口属性中的作用与类中的作用略有不同.

public interface IAggregationView
{
   DataTable SetSiteData { set; }
}

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

该接口指定该属性至少应具有公共setter.getter的定义和可访问性留给实现类.

所以如果接口契约只需要写,get就可以保持打开状态.无需要求公众获得.

因此,您无法在接口中真正指定只读属性.只有'至少读取权限'.

interface IFoo
{
    int Id { get;  }
}

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

Answer 3

我可以想象将它用于（手动）依赖注入。一个类可能需要注入一个仅在内部使用的协作者。当然，人们通常会选择在类的构造函数中执行此操作，但有时可能希望在运行时更改合作者。