Question

起初看起来很自然 - 如果一组目录不存在，那么对它们起作用的对象将无法履行其合同。所以在构造函数中我有一些逻辑来检查是否存在某些目录，如果没有则创建它们。虽然实际上还不是单身人士，但这个对象就像一个人一样使用。

构造函数是否适合这种设置逻辑？

背景
该类称为FileGetter。它抽象从远程服务器获取特定文件，提取它们，准备文件并将它们放在另一个目录中，其中第二个类将是文件系统处理/处理数据。

Answer 1

来自Inversion of Control or Dependency Inversion perspective，是的，这是不正确的。

您声明在目录上工作的对象如果不存在则无法正常工作。我将提供和检查/创建目录的内容抽象到另一个抽象中，然后将该抽象的实现传递给您的对象。

然后，你的对象只需从这个抽象中获取目录并从那里继续。

举个例子，这就是我的意思。首先，有目录提供程序的抽象，如下所示：

public interface IDirectoryProvider
{
    // Gets the full paths to the directories being worked on.
    IEnumerable<string> GetPaths();
}

然后是实施。

public sealed class DirectoryProvider
{
    public DirectoryProvider(IEnumerable<string> directories)
    {
        // The validated directories.
        IList<string> validatedDirectories = new List<string>();

        // Validate the directories.
        foreach (string directory in directories)
        {
            // Reconcile full path here.
            string path = ...;

            // If the directory doesn't exist, create it.
            Directory.CreateDirectory(path);

            // Add to the list.
            validatedDirectories.Add(path);
        }
    }

    private readonly IEnumerable<string> _directories;

    public IEnumerable<string> GetPaths()
    {
         // Just return the directories.
         return _directories;
    }
}

最后，您的类处理目录，如下所示：

public sealed DirectoryProcessor
{
    public DirectoryProcessor(IDirectoryProvider directoryProvider)
    {
        // Store the provider.
        _directoryProvider = directoryProvider;
    }

    private readonly IDirectoryProvider _directoryProvider;

    public void DoWork()
    {
        // Cycle through the directories from the provider and
        // process.
        foreach (string path in _directoryProvider.GetPaths())
        {
            // Process the path
            ...
        }
    }
}

Answer 2

我会说这取决于。一般来说，使对象构造尽可能便宜是一个好主意;也就是说，让构造函数包含尽可能少的逻辑。这反对在构造函数中创建目录。另一方面，如果没有目录，对象实际上根本无法运行，那么尽早失败可能是个好主意（例如，如果由于某种原因无法创建目录）。这可以说是在构造函数中创建它们。

就我个人而言，我可能倾向于而不是在构造函数中创建它们，而是让每个需要它们的方法调用一些创建目录的方法，如果还没有完成的话。

Answer 3

您可以使用逻辑来处理类本身或将使用该类的每一段代码中缺少文件夹。

真的，选择取决于你。如果你选择将它放在类本身，构造函数是一个非常好的地方，因为构造函数可以“设置”类以及它需要运行的所有东西。

Answer 4

我喜欢casperOne's answer。不过我会考虑以下内容：

创建此独特对象的频率。
正在创建多少个目录。
构造函数用于创建目录的频率
您是否需要有关目录状态的反馈
您是否需要有关目录不存在或任何其他错误的原因的反馈。
最后但并非最不重要：是否值得努力思考另一种方式？

根据这些问题，您可能会发现这只是在对象生命周期中调用一次的情况。它不应该失败，如果它做了别的事情就完全出错了。所以我决定将逻辑保持原样。

如果您有时间并考虑扩展程序，请在其他地方使用该类，或者创建更多目录，如casperOne所述，创建目录提供程序可能是值得的。如果正在创建多个目录，不止一次，例如在每次启动程序时和/或您可以重用代码并尽可能灵活...那么我强烈建议使用目录提供者，从而使对象更灵活，并减少在构造函数内创建SPOF的机会。

Answer 5

我认为构造函数确实就是这样的东西吗？

在构造函数中创建目录是一个坏主意吗？

5 个答案: