Лучшая практика при создании классов, которые отвечают исключительно за создание других объектов, например, фабрик? - PullRequest
Новая
       40

Лучшая практика при создании классов, которые отвечают исключительно за создание других объектов, например, фабрик?

0 голосов
/ 20 июня 2019

Я часто создаю классы с суффиксом 'Factory'.Эти классы, как правило, отвечают исключительно за создание определенного класса или набора связанных классов.Однако я всегда чувствовал, что это, вероятно, не лучшая практика и что есть лучший способ приблизиться к этому.Одна из причин, по которой я считаю, что это не лучшая практика, заключается в том, что, хотя я использую суффикс «Фабрика», я на самом деле не использую шаблон фабричного проектирования.

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

public class VehicleFactory
{
    public Vehicle CreateVehicle(string make, string model)
    {
         //create vehicle..
         return vehicle;
    }
}

Затем можно использовать VehicleFactory в моей программе, где бы я ни хотел, без повторения кода и нарушения DRY.

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

Есть ли лучший способ решения этой проблемы?

Ответы [ 2 ]

0 голосов
/ 20 июня 2019

Существует 3 общих подхода к созданию объектов:

  1. Конструкторы
  2. Статические фабричные методы
  3. Фабричные классы (не говоря об абстрактной фабричной модели, так как вы ужеопределил, что вы его не используете)

Я считаю, что этот список также находится в порядке приоритета.Конструкторы должны быть предпочтительнее, потому что это наиболее очевидное место, куда разработчик мог бы взглянуть при создании экземпляра объекта.Недостатком является то, что конструкторы имеют несколько ограничений: имя должно соответствовать имени класса, которое ограничивает перегрузку, а конструктор должен «возвращать» создаваемый класс.

Если вам нужно предоставить несколько перегрузок с одной и той же сигнатуройЗдесь статические фабричные методы могут быть полезны (или просто для предоставления более описательных имен методов в целом).Например: CreateVehicleWithName(string name) и CreateVehicleWithColor(string color) было бы невозможно сделать с конструкторами.В другом случае вы хотите разрешить возврат null, если параметры недопустимы или какой-либо другой объект результата вместо экземпляра самого класса.Обратите внимание, что эти статические методы фабрики часто лучше всего определять как часть класса.

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

В заключение, передовой опыт: определите конструктор, если можете;используйте фабричный класс только тогда, когда конструкторы и статические фабричные методы неосуществимы.

0 голосов
/ 20 июня 2019
Шаблон

Factory скорее для более сложных сценариев, таких как наличие общего интерфейса для конкретных классов, тогда класс Factory создаст подходящие объекты конкретного класса.

В вашем сценарии код может быть размещен непосредственно в конструкторе класса.

Читать это например:)

...