Этот шаблон создания Метода фабрики?

I would agree to call the method a "Factory Method", though the design is not strictly a "Factory Method Pattern".

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

The simplest explanation of the factory pattern, which I learned from a patterns and practice class, was that if you rely on another class to create the instances of your class, then you're using the factory pattern.

Of course, often times you want to add a layer of indirection by making your class abstract or an interface.

This is very simplified view of it, but either way, you are using the factory pattern.

Это фабричный шаблон учебника.

Некоторые тексты называют его простым Factory Patteren, но я никогда не видел никаких критериев для того, что означает «Simple».

В моей практике Factory Pattern - это любое интеллектуальное создание конкретного класса, основанного на желаемом интерфейсе.

Но зачем бороться с вашей технологией? привести имя метода.

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

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

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

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

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

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

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

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

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

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

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

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

Да, это нормально, заводская модель. Ваш технический руководитель не прав.

Ну, Википедия говорит , что это фабричный метод:

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.
        }
    }
}

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

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

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

Из Шаблон фабричного метода :

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

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

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

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

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

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

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

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

Бетонная фабрика создаст ваш IScheduleItem (оставляя его на самом деле для создания конкретного типа).

В конце я думаю, что весь смысл Слабая связь. Хотя «простая» фабрика слабо связывает конструкцию продукта с клиентом, она не отделяет фабрику. Фабричный образец также разъединяет фабричный.

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

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

Simple Factory Простая фабрика http://yuml.me/7221a4c9 Шаблон заводского метода Шаблон заводского метода http://yuml.me/3d22eb4e[1270 impression

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

GoF:

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

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

Реализовали ли вы его неправильно все эти годы? Нет, вы просто не реализовали фабричный шаблон, но то, что иногда называют «простым фабричным шаблоном», который, вероятно, отлично справился со своей задачей.