仅设置属性是不好的做法吗？ [复制]

Question

我有一些 C# 代码喜欢创建具有 setter 但没有 getter 的属性。对我来说，这似乎是一种反模式，但我是否遗漏了什么？

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

Answer 1

我不知道我是否称它为反模式。我认为要意识到的重要一点是，您示例中的属性本质上是一个方法，伪装成一个属性。出于这个原因，它是不直观的，我通常会避免它。对我来说，这看起来更自然：

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

我看到的一个相当合理的情况是，当有几个属性组合在一起时，将所有属性设置为单个值是合理的做法（但显然，getting全部作为一个值没有意义）。例如：

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

这对于Dependency Injection 可能很有用，在这种情况下，您使用属性而不是使用构造函数进行注入。

Answer 3

我认为这种做法本身并没有什么不好的地方，尽管它对我来说没有多大意义。

封装的意义在于限制可以改变对象状态的因素，从而使状态变得更易于维护。我想不出任何充分的理由将属性设为只写。而且，如果可以的话，将其作为一种方法可能更有意义。

用户习惯于能够读取属性，他们可能会浪费时间想知道为什么您的属性如此奇怪。

Answer 4

如果您期望发生很多逻辑，那么通过使用一种方法来设置它似乎更清楚成本。

Answer 5

这可能不是每个人都喜欢的，但我posted an answer to another question 演示了“注入器”概念的使用，在本例中是嵌套在不可变结构中的结构。 infuser 具有只写属性，补充了不可变类型的只读属性。

公平地说，我同意这种方法可能会造成混淆，在将这样的代码包含在不仅仅是一个业余项目的应用程序中之前，我会三思而后行。

这个概念对于普通类也很有用，而不仅仅是不可变类型。它允许负责实例化对象的代码对该对象中包含的数据进行读/写访问。然后可以将该对象传递给其他代码，该代码对对象内的数据具有只读访问权限。

Answer 6

这样的做法还不错，只是不是很有用（您看不懂的属性？）。

Answer 7

这真的是一件很奇怪的事情。你为什么要编写一个允许用户设置列表但不读取它的 API？如何改为返回 ReadOnlyCollection 并将属性公开为 IList 而不是 List？