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

| 乍一看,这似乎很自然-如果不存在一组目录,则在其上工作的对象将无法履行其合同。因此,在构造函数中,我有一些逻辑来检查是否存在某些目录,如果不存在则创建它们。尽管实际上还不是单例对象,但该对象的使用就像一个对象。 构造函数是否对这种设置逻辑不利? 背景 该类称为FileGetter。它抽象了从远程服务器获取特定文件,提取它们,准备文件并将它们放置在另一个目录中的另一个目录,该目录中的第二类将是文件系统监视/处理数据。     
已邀请:
从控制反转或依赖反转的角度来看,是的,这是不正确的。 您声明,如果目录中不存在的对象无法工作,那么它们将无法工作。我将目录的提供和检查/创建抽象为另一个抽象,然后将该抽象的实现传递给您的对象。 然后,您的对象只需从该抽象中获取目录,然后从那里继续。 举例来说,这就是我的意思。首先,存在目录提供程序的抽象,如下所示:
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
            ...
        }
    }
}
    
我会说这取决于。一般来说,使对象构造尽可能便宜是一个好主意。也就是说,使构造函数包含尽可能少的逻辑量。这不利于在构造函数中创建目录。另一方面,如果没有目录该对象实际上根本无法运行,那么最好尽早执行失败(例如,由于某种原因而无法创建目录)。这可能代表在构造函数中创建它们。 就我个人而言,我可能倾向于不在构造函数中创建它们,而是让每个需要它们的方法调用某个创建目录的方法(如果尚未创建)。     
您可以在类本身或将占用该类的每段代码中放入处理缺少文件夹的逻辑。 选择实际上取决于您。如果选择将其放在类本身中,则构造函数非常适合它,因为构造函数可以“设置”该类及其所需的所有功能。     
我喜欢casperOne的回答。但是我会考虑以下内容: 此独特对象多久创建一次。 正在创建多少个目录。 构造函数多久用于创建一个目录 您是否需要有关目录状态的反馈 您是否需要有关目录不存在或任何其他错误的原因的反馈。 最后但并非最不重要的一点:值得尝试另一种方式吗? 根据这些问题,您可能会意识到,这只是对象生命周期中一次被调用的情况。它不应失败,并且如果执行其他操作,则将完全出错。因此,我决定保持逻辑不变。 如果您有时间并且打算扩展程序,请在其他地方使用该类,或者创建更多目录,如casperOne所述,可能值得创建目录提供程序。如果要创建一个以上的目录,例如在程序的每个开始处创建多个目录,并且/或者您可以重用代码并尽可能灵活……那么,我强烈建议您使用目录提供者,从而使对象更加灵活,并减少了在构造函数内部创建SPOF的机会。     
我认为有一种构造器可用于这种事情?     

要回复问题请先登录注册