Этот шаблон создания Factory?

Я использую шаблон создания метода factory еще некоторое время. Недавно мне сказали, что это:

public static class ScheduleTypeFactory
{
    public static IScheduleItem GetScheduleItem(ScheduleTypeEnum scheduleType)
    {
        IScheduleItem scheduleItem = null;

        switch (scheduleType)
        {
            case ScheduleTypeEnum.CableOnDemandScheduleTypeID:
                {
                    scheduleItem = new VODScheduleItem();
                    break;
                }
            case ScheduleTypeEnum.BroadbandScheduleTypeID:
                {
                    scheduleItem = new VODScheduleItem();
                    break;
                }
            case ScheduleTypeEnum.LinearCableScheduleTypeID:
                {
                    scheduleItem = new LinearScheduleItem();
                    break;
                }
            case ScheduleTypeEnum.MobileLinearScheduleTypeID:
                {
                    scheduleItem = new LinearScheduleItem();
                    break;
                }
        }

        return scheduleItem;
    }
}

не является шаблоном создания метода factory моим руководством "Tech", не сообщая мне, почему или давая мне ее интерпретацию. Я любезно попросил объяснений, и она сказала, что у нее нет времени. Мне сказали просто переименовать его. Если я ошибаюсь, то я, без сомнения, соглашусь с тем, что я неправильно выполнил это в течение многих лет. Это как ВАМ реализовать шаблон создания метода factory? Спасибо заранее.

Ответ 1

Я бы согласился называть метод "Factory Method", хотя дизайн не является строго "шаблоном метода Factory".
Вот ключевой момент (из Википедии):

... Метод Factory позволяет классу отложить экземпляр к подклассам.

Так как ваш класс статичен и статический статический (следовательно, не виртуальный), "отсрочки" не существует.

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

Сказав это, та же статья в Википедии представляет эту схему как вариант шаблона метода Factory.

Резюме сводки: по моему мнению, этот фрагмент не является надлежащей реализацией "Factory метода OO Design Pattern", так как он не удовлетворяет "экземпляр класса для последующего подкласса". Хотя, лично я бы свободно ссылался на это решение как "Factory method".

Чтобы сделать это реальным шаблоном метода Factory, вам нужно разрешить переопределение метода подклассами. То есть Factory class (ScheduleTypeFactory) должен быть расширяемым (т.е. нестатическим), а GetScheduleItem должен быть виртуальным.

Ответ 2

Для меня это выглядит как factory. Я не вижу ничего плохого в вашей реализации.

Из Factory шаблон метода:

Сущность шаблона factory "Определить интерфейс для создания объект, но пусть подклассы решить, какой класс необходимо создать. factory позволяет классу отложить экземпляр для подклассов."

Это именно то, что вы делаете.

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

Ответ 3

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

default:
  throw new InvalidOperationException("Invalid Enum Value");

Ответ 4

Ваш фрагмент кода в Head First Design Patterns называется "Простой Factory" (стр. 117).
Основное отличие от Factory Method Pattern - это ConcreteCreator (сравнить диаграмму в правом верхнем углу), который является простым классом в вашем случае.
В" реальном шаблоне" класс factory является абстрактным с абстрактным классом factory. Итак, есть еще один уровень абстракции. Однако для многих случаев использования достаточно Simple Factory.

Простой Factory Простой factory http://yuml.me/7221a4c9 Factory Шаблон метода Factory Шаблон метода http://yuml.me/3d22eb4e

Ответ 5

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

Ответ 6

Ваше лидерство верное (извините за форматирование, но для этого ответа требуется часть его, чтобы быть видимым между основной линией, в которой указано, что это притворство): ни GOF book или Head Сначала это метод factory.

GoF:

"Определите интерфейс для создания объект, но пусть подклассы какой класс для создания экземпляра. FactoryМетод позволяет классу отложить экземпляр для подклассов."

В вашем примере это не подкласс, который решает.

Вы выполняли это неправильно все эти годы? Нет, вы просто не реализовали шаблон factory, но иногда называемый "Simple factory Pattern", который, вероятно, отлично справился с заданием.

Ответ 7

Похож на (базовый) factory на меня... на многих фабриках реализация более сложна (возможно, включает типы, разрешенные во время выполнения), но это не требование (AFAIK). Единственная другая критика, которую я добавил бы, это объединить дела и сделать что-то более драматичное, если вы не узнаете тип...

Ответ 8

Я удивлен, поэтому многие говорят, что это шаблон factory. (Скорее всего, я думаю об этом неправильно, поэтому, пожалуйста, дайте мне знать.)

Мне кажется, что у вас есть только часть дизайна. Если вы вызываете его у своего клиента, он называется "простым" factory, но он не считается шаблоном проектирования. (Не поймите меня неправильно, я делаю это все время).

В шаблоне проектирования factory указано, что ваш factory наследует/реализует абстрактный factory/заводский интерфейс.

Затем в вашем классе, который должен использовать factory (клиент), вы устанавливаете тип factory в абстрактный/интерфейс, создавая конкретный factory: т.е. → IFactory factory= новый ConcreteFactory();

Конкретный factory создаст ваш IScheduleItem (оставив его factory, чтобы создать конкретный тип).

В конце концов, я думаю, что речь идет о развязке. В то время как "простой" factory свободно соединяет конструкцию продукта с клиентом, он не отделяет factory. Образец factory также отделяет factory.

Опять же, рано, у меня не было кофе, и у меня есть неприятная привычка публиковать абсолютно ужасные ответы, которые не соответствуют всей точке вопроса.

Ответ 9

Ну, Wikipedia говорит это метод factory:

public class ImageReaderFactory 
{
    public static ImageReader getImageReader( InputStream is ) 
    {
        int imageType = figureOutImageType( is );

        switch( imageType ) 
        {
            case ImageReaderFactory.GIF:
                return new GifReader( is );
            case ImageReaderFactory.JPEG:
                return new JpegReader( is );
            // etc.
        }
    }
}

Ответ 10

Это шаблон Factory, но это не обязательно самый поддерживаемый вариант. Более поддерживаемый вариант будет поддерживать некоторую глобальную карту между значениями ScheduleTypeEnum и фактическими конкретными подтипами IScheduleItem - таким образом, вы можете заменить оператор switch на поиск карты.

Почему он более удобен в обслуживании?. Поскольку авторы подкласса могут добавлять пары к карте на сайте, где они получают класс, а не в самой функции GetScheduleItem() Factory. Следовательно, последнее никогда не нуждается в обновлении; он постоянно обновляется.

В С++ вы можете сделать это с помощью глобального std::map - для каждого конкретного подкласса, автор подкласса добавляет фиктивную глобальную переменную, которая фактически просто регистрирует класс (путем добавления к карте) в своем конструкторе, который работает во время запуска программы. Я уверен, что есть удобный способ сделать то же самое в С#.

(С++ гуру Herb Sutter имеет развлекательное описание здесь, но оно довольно С++ - тяжелое.)

Ответ 11

Похож на шаблон factory для меня. Скажите, что ваше техническое руководство не имеет времени, чтобы объяснить, почему она ошибается.

Ответ 12

Это действительно "factory", поскольку у вас есть метод, который возвращает конкретный экземпляр IScheduleItem на основе какой-то логики; однако, вероятно, это не самая лучшая реализация или самая удобная в обслуживании, учитывая, что вы используете оператор switch.

Ответ 13

Yup, что шаблон factory в порядке. Неправильный вывод Tech Tech.

Ответ 14

Похож на базовый шаблон factory для меня. Мне любопытно узнать, почему ваш технический руководитель не считает, что это образец.

Я также разочарован, что не будет тратить время на объяснение. Будучи техническим лидером перед командой, важно не торопиться, чтобы объяснить ваши решения.

Ответ 15

Это шаблон метода factory, по крайней мере, согласно Википедии: http://en.wikipedia.org/wiki/Factory_method_pattern

Ответ 16

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

Тот факт, что Википедия перечисляет ваш шаблон в качестве примера, показывает, что он правильно является шаблоном Factory. Шаблоны были определены, чтобы обеспечить общий язык для общих решений, поэтому ясно, если Википедия показывает это в качестве примера, это часть общего языка. Академическая дискуссия о том, что "Factory Pattern" находится в каком-то абстрактном смысле, пропускает точку шаблонов.

Ответ 17

Возьми власть прямо сейчас! Просто отбросьте "Тип" из формулировки. ScheduleFactory FTW. Подождите, это factory для "Расписаний" или "ScheduleItems"? Если это запланировано, то factory следует называть "ScheduleItemFactory". Будьте выразительны!!!

Ответ 18

Простейшим объяснением шаблона factory, который я узнал из шаблона и класса практики, было то, что если вы полагаетесь на другой класс для создания экземпляров своего класса, то вы используете шаблон factory.

Конечно, часто вы хотите добавить слой косвенности, создав абстрактный класс или интерфейс.

Это очень упрощенное представление об этом, но в любом случае вы используете шаблон factory.

Ответ 19

Ваша технология права на переименование метода:

public static IScheduleItem GetScheduleItem(ScheduleTypeEnum scheduleType)

Действие метода заключается не в том, чтобы что-то получить, а в создать. Как вы определяете, какой тип schedType должен быть создан? Кажется, что логика должна быть инкапсулированным не коммутатором типа.

Также почему статический в классе? Где вы его используете?

public class ScheduleTypeFactory
{
    public static IScheduleItem createScheduleFrom(ScheduleTypeEnum scheduleType)
    {

        switch (scheduleType)
        {
            case ScheduleTypeEnum.CableOnDemandScheduleTypeID:
            case ScheduleTypeEnum.BroadbandScheduleTypeID:
                 return new VODScheduleItem();
             case ScheduleTypeEnum.LinearCableScheduleTypeID:
             case ScheduleTypeEnum.MobileLinearScheduleTypeID:
                    return new LinearScheduleItem();
        }

       raise InvalidSchedule;
    }
}

Ответ 20

Вот учебник Factory Шаблон.

Некоторые тексты называют это простым Factory Patteren, но я никогда не видел никаких критериев для того, что означает "Простой".

В моей практике шаблон Factory представляет собой любое интеллектуальное создание конкретного класса, отвечающего требуемому интерфейсу.

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