Как правильно создавать объекты?

315

11 ноября 2017, 10:32

Слышал что не рекомендуется использовать оператор new где попало. Его необходимо изолировать в отдельном классе который будет отвечать за создания объектов? Как правильно реализовать подобную фабрику, я сделал статический класс Factory, который умеет создавать любой объект. Но я не уверен что это надо делать именно статическим классом, и что будет когда различных видов классов будет много, не будет ли слишком перегружен?

public static class Factory
{
    public static Object CreateExcelBuilder()
    {
        try
        {
            ExcelBuilder excelBuilder = new ExcelBuilder();
            return excelBuilder;
        }
        catch (Exception ex)
        {
            string text = "Factory CreateExcelBuilder(): Возникла проблема при создании объекта excelBuilder класса ExcelBuilder. Подробности: " + ex.ToString();
            Log.SetError(text);
            return null;
        }
    }

Answer 1

Думаю, что вы слыхали об этом в контексте внедрения зависимостей (dependency injection). В этом контексте утверждение о том, что нужно более гибкое создание объектов, чем простой вызов конструктора, имеет смысл.

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

interface IImageSaver
{
    Task Save(Image image, string name);
}

и несколько реализаций:

class FileSystemImageSaver : IImageSaver { ... }
class PipeImageSaver : IImageSaver { ... }
class AppleICloudImageSaver : IImageSaver { ... }
class GoogleDriveImageSaver : IImageSaver { ... }

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

Вы работаете с сохранением картинок только через интерфейс IImageSaver.
Вы нигде не создаёте экземпляры IImageSaver вручную.
У вас есть фабрика, которая и создаёт вам IImageSaver. Она каким-т образом конфигурируется в начале работы программы, и знает, какой именно конкретный тип нужно создавать.

Тем самым знание о том, с каким же конкретно типом вам нужно работать, получается не размазано по программе, а сосредоточено в одном месте — в фабрике.

После этого длинного вступления давайте вернёмся к вашему вопросу.

Нет, писать универсальную фабрику, которая умеет создавать вообще любой объект, я бы не стал. Хотя бы потому, что гибкость внедрения зависимостей нужна вам реально только для некоторых классов, очень малой части всех классов вашего приложения. Ну и не забывайте, что создание классов через фабрику всё же медленнее, чем вручную, и гораздо менее удобно.

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

Если объектов, для которых вам нужна кастомная логика создания, много, имеет смысл не писать вручную, а воспользоваться dependency injection. В этом случае ваш DI-фреймворк обычно предоставляет вам общую фабрику, в которой вы пишете что-то наподобие container.Resolve<IImageSaver>().