Это плохая идея создавать каталоги в конструкторе? - PullRequest
3 голосов
/ 14 апреля 2011

Сначала это казалось естественным - если бы набор каталогов не существовал, объект, работающий с ними, не смог бы выполнить свои контракты.Так что в конструкторе у меня есть логика, чтобы проверить, существуют ли некоторые каталоги и создать их, если нет.Хотя на самом деле это еще не единичный объект, этот объект используется как единое целое.

Является ли конструктор плохим местом для такого рода логики настройки?

Фон
класс называется FileGetter.Он абстрагируется от получения определенных файлов с удаленного сервера, их извлечения, подготовки файлов и помещения их в другой каталог, где вторым классом будет файловая система для наблюдения / обработки данных.

Ответы [ 5 ]

8 голосов
/ 14 апреля 2011

С точки зрения Инверсия управления или Инверсия зависимости , да, это неправильно.

Вы утверждаете, что объект, который работает в каталогах, не может выполнять свою работу, если они не существуют. Я бы абстрагировал предоставление и проверку / создание каталогов в другую абстракцию, а затем передал бы реализацию этой абстракции вашему объекту.

Тогда ваш объект просто получит каталоги из этой абстракции и продолжит оттуда.

В качестве примера, вот что я имею в виду. Во-первых, существует абстракция поставщика каталогов, например:

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
            ...
        }
    }
}
5 голосов
/ 14 апреля 2011

Я бы сказал, что это зависит.В общем, хорошая идея сделать строительство объекта как можно дешевле;то есть, чтобы конструкторы содержали как можно меньше логики.Это говорит против создания каталогов в конструкторе.Если, с другой стороны, объект действительно не может работать вообще без каталогов, может быть хорошей идеей будет провал как можно раньше (например, в случае, если каталоги не могут быть созданы по какой-либо причине).Это может говорить о создании их в конструкторе.

Лично я бы, вероятно, склонялся к созданию , а не в конструкторе, но вместо этого каждый метод, который нуждается в них, вызывает некоторый метод, который создает каталоги., если это еще не сделано.

2 голосов
/ 14 апреля 2011

Вы можете использовать логику для решения проблемы отсутствия папок в самом классе или в каждом фрагменте кода, который будет использовать этот класс.

Выбор действительно за вами. Если вы решите поместить его внутрь самого класса, конструктор станет для него идеальным местом, так как конструктор предназначен для «настройки» класса и всего, что ему необходимо для функционирования.

1 голос
/ 14 апреля 2011

Мне нравится ответ casperOne .Однако я хотел бы рассмотреть следующие вещи:

  1. Как часто создается этот отдельный объект.
  2. Сколько каталогов создается.
  3. Как часто будет использоваться конструктордля создания каталога
  4. Вам понадобится отзыв о состоянии каталога
  5. Вам понадобится отзыв о причине отсутствия каталога или любой другой ошибке.
  6. и последнее, но не менее важное: стоит ли думать об ином способе?

В зависимости от этих вопросов вы можете понять, что это просто однажды вызванная ситуация за время существования объекта.Он не должен потерпеть неудачу, и если он делает что-то еще, то все идет не так, как надо.Поэтому я бы решил сохранить логику там, где она есть.

Если у вас есть время и вы хотите расширить программу, использовать класс в другом месте или, возможно, создать гораздо больше каталогов, возможно, стоит создать поставщика каталогов.как описано casperOne.Если создается более одного каталога, более одного раза, например, при каждом запуске программы, и / или у вас есть возможность повторно использовать код и быть максимально гибким ... тогда я настоятельно рекомендую использовать каталогпоставщика, тем самым делая объект более гибким и уменьшая вероятность создания SPOF внутри конструктора.

0 голосов
/ 14 апреля 2011

Я думаю, что конструктор предназначен именно для такого рода вещей?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...