Question

我试图找出为类的消费者构建类的最佳方法，以便能够以最少的努力使用它们。

鉴于以下两个例子：

public class Foo
{

    public List<Bar> Bars { get; private set; }

    public Foo()
    {
        Bars = new List<Bar>();
        Method1();
        Method2();
    }

    private void Method1()
    {
        // code
    }

    private void Method2()
    {
        // code
    }
}

在这个例子中，类的使用者不需要知道如何使用类，并且（假设method1 / 2对Bars执行某些操作），用户只需要实例化该类以获取所需的信息 - Bars

或者应该这样做（或完全不同的事情）：

public class Foo
{

    public List<Bar> Bars { get; private set; }

    public Foo()
    {
        Bars = new List<Bar>();
    }

    public void DoStuff()
    {
        Method1();
        Method2();
    }

    private void Method1()
    {
        // code
    }

    private void Method2()
    {
        // code
    }
}

在这种情况下，消费者需要知道调用DoStuff（）才能正确使用该类。在类变得臃肿的情况下，如果用户需要弄清楚调用方法的顺序，这对用户来说可能会非常混乱。在这个例子中，我知道在最佳实践中，类应该很薄并且遵循SRP，但如果不是这样的话，是否有理由采用一种方法与另一种方法相比？

有点相关，因为我的Method1和Method2操纵我的Bars中的数据，是否有一个规则/最佳实践，关于Method1和Method2是否接受List的参数然后应用于Bars，或者它是否可以工作直接使用Bars而不将参数带入对象。是否有理由做另一个？

Answer 1

在构建类时，不调用这两种方法是否有正当理由？

在构建实例之后的某个时间点是否有正当理由调用这两种方法？

在给定实例上多次调用这些方法是否无效？

如果上述任何一种情况属实，那么您的第一个选项中无法使用该功能，但它位于您的第二个选项中。如果该功能实际上很重要，那么第一个选项*不提供所需的功能。

如果上述所有问题都是“否”，则第二个问题不是真正的选择。您正在提供消费者只能做错事的功能。他们只是做不完全正确的事情而破坏事物，所以你也可以为他们做正确的事情，而不是让他们有机会弄错。

另一方面，如果第一个选项没有提供所需的功能，但仍然存在某些约束（即无法多次调用它们，但希望推迟工作如果可能的话，在完成这项工作之前无法调用其他方法，等等。那么几率都是错误的。您需要非常明确地了解您的实际约束，以及所有必需（也可能是很好的）功能，以尝试找到满足所有约束的解决方案，同时仍然提供所有必需的功能。

Answer 2

好像你已经回答了自己的问题。您是否有更具体的示例可能会更清楚您为什么考虑第二个示例？

构造函数应该尽一切可能初始化类，以便它可以像第一个例子一样使用它。由于Bars是从用户的角度来看是只读的，并且因为显然初始化Bars列表并且包含Bar对象的DoStuff（）方法不接受任何参数，所以它应该在构造

如何构建类以便从消费者和测试中最容易理解

2 个答案: