Фабрика узоры в перово: Фабрика «Узоры» — Москва

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

• Классы абстрактной фабрики часто основаны на наборе фабричных методов, но вы также можете использовать Prototype для компоновки методов в этих классах.

• Вы можете использовать Factory Method вместе с Iterator, чтобы подклассы коллекций возвращали различные типы итераторов, совместимых с коллекциями.

• Prototype не основан на наследовании, поэтому у него нет недостатков. С другой стороны, Prototype требует сложной инициализации клонированного объекта.Заводской метод основан на наследовании, но не требует шага инициализации.

• Factory Method — это специализация шаблонного метода. В то же время заводской метод может служить шагом в большом методе шаблона .

Шаблон фабричного метода и его реализация на Python — Real Python

В этой статье исследуется шаблон проектирования Factory Method и его реализация в Python.Шаблоны проектирования стали популярной темой в конце 90-х после того, как так называемая «Банда четырех» (GoF: Gamma, Helm, Johson и Vlissides) опубликовала свою книгу «Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения».

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

Книга GoF описывает фабричный метод как творческий шаблон проектирования. Шаблоны проектирования создания связаны с созданием объектов, а фабричный метод — это шаблон проектирования, который создает объекты с общим интерфейсом.

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

К концу этой статьи у вас будет :

• Понимание компонентов заводского метода
• Распознать возможности использования заводского метода в ваших приложениях
• Научитесь изменять существующий код и улучшать его дизайн с помощью шаблона
• Научитесь определять возможности, в которых заводской метод является подходящим шаблоном проектирования
• Выберите подходящую реализацию заводского метода
• Знать, как реализовать многоразовое универсальное решение Factory Method

Бесплатный бонус: 5 мыслей о Python Mastery, бесплатный курс для разработчиков Python, который показывает вам план действий и образ мышления, которые вам понадобятся, чтобы вывести свои навыки Python на новый уровень.

Знакомство с заводским методом

Factory Method — это шаблон проектирования, используемый для создания конкретных реализаций общего интерфейса.

Он отделяет процесс создания объекта от кода, который зависит от интерфейса объекта.

Например, приложению требуется объект с определенным интерфейсом для выполнения своих задач. Конкретная реализация интерфейса идентифицируется некоторым параметром.

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

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

  # В serializer_demo.ру

импортировать json
импортировать xml.etree.ElementTree как et

класс Песня:
    def __init __ (self, song_id, title, artist):
        self.song_id = song_id
        self.title = title
        self.artist = художник


класс SongSerializer:
    def сериализовать (self, song, format):
        если format == 'JSON':
            song_info = {
                'id': song.song_id,
                'title': song.title,
                'исполнитель': song.artist
            }
            вернуть json.dumps (song_info)
        elif format == 'XML':
            song_info = et.Элемент ('песня', attrib = {'id': song.song_id})
            title = et.SubElement (song_info, 'название')
            title.text = song.title
            исполнитель = et.SubElement (song_info, 'исполнитель')
            artist.text = song.artist
            вернуть et. tostring (song_info, encoding = 'unicode')
        еще:
            поднять ValueError (формат)
  

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

Метод .serialize () поддерживает два разных формата: JSON и XML. Любой другой указанный формат не поддерживается, поэтому возникает исключение ValueError .

Давайте воспользуемся интерактивной оболочкой Python, чтобы увидеть, как работает код:

  >>> импортировать serializer_demo как sd
>>> song = sd.Song ('1', 'Вода любви', 'Ужасные проливы')
>>> сериализатор = sd.SongSerializer ()

>>> сериализатор.сериализовать (песня, 'JSON')
'{"id": "1", "title": "Вода любви", "artist": "Dire Straits"}'

>>> serializer. serialize (песня, 'XML')
'   Dire Straits  '

>>> serializer.serialize (песня, 'YAML')
Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
  Файл "./serializer_demo.py", строка 30, в сериализации
    поднять ValueError (формат)
ValueError: YAML
  

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

Проблемы со сложным условным кодом

В приведенном выше примере показаны все проблемы, которые вы обнаружите в сложном логическом коде. Сложный логический код использует структуры if / elif / else для изменения поведения приложения. Использование условных структур if / elif / else затрудняет чтение, понимание и сопровождение кода.

Приведенный выше код может показаться несложным для чтения или понимания, но подождите, пока вы не увидите окончательный код в этом разделе!

Тем не менее, приведенный выше код сложно поддерживать, потому что он делает слишком много. Принцип единой ответственности гласит, что модуль, класс или даже метод должны иметь единственную четко определенную ответственность. Он должен делать только одно и иметь только одну причину для изменения.

Метод . serialize () в SongSerializer потребует изменений по разным причинам.Это увеличивает риск появления новых дефектов или нарушения существующей функциональности при внесении изменений. Давайте рассмотрим все ситуации, которые потребуют изменений в реализации:

• Когда будет представлен новый формат: Метод необходимо будет изменить, чтобы реализовать сериализацию в этом формате.

• При изменении объекта Song : Добавление или удаление свойств класса Song потребует изменения реализации, чтобы приспособиться к новой структуре.

• При изменении строкового представления для формата (простой JSON против JSON API): Метод .serialize () должен измениться, если желаемое строковое представление для формата изменится, потому что представление жестко закодировано в Реализация метода .serialize () .

Идеальная ситуация была бы, если бы любое из этих изменений требований могло быть реализовано без изменения метода . serialize () .Давайте посмотрим, как это сделать, в следующих разделах.

В поисках общего интерфейса

Первым шагом, когда вы видите сложный условный код в приложении, является определение общей цели каждого из путей выполнения (или логических путей).

Код, использующий if / elif / else , обычно имеет общую цель, которая реализуется по-разному на каждом логическом пути. Приведенный выше код преобразует объект песни в его представление строки , используя другой формат в каждом логическом пути.

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

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

Затем вы предоставляете отдельный компонент, который определяет конкретную реализацию для использования на основе указанного формата .Этот компонент оценивает значение формата и возвращает конкретную реализацию, идентифицированную его значением.

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

Мартин Фаулер в своей книге «Рефакторинг: улучшение дизайна существующего кода» определяет рефакторинг как «процесс изменения программной системы таким образом, чтобы не изменять внешнее поведение кода, но улучшать его внутреннюю структуру.”

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

Реорганизация кода в требуемый интерфейс

Требуемый интерфейс — это объект или функция, которая принимает объект Song и возвращает строковое представление .

Первым шагом является рефакторинг одного из логических путей в этот интерфейс. Вы делаете это, добавляя новый метод ._serialize_to_json () и перемещая в него код сериализации JSON.Затем вы меняете клиента для его вызова вместо реализации в теле оператора if :

  класс SongSerializer:
    def сериализовать (self, song, format):
        если format == 'JSON':
            return self._serialize_to_json (песня)
        # Остальной код остается прежним

    def _serialize_to_json (я, песня):
        payload = {
            'id': song.song_id,
            'title': song.title,
            'исполнитель': song.artist
        }
        вернуть json.свалки (полезная нагрузка)
  

После внесения этого изменения вы можете убедиться, что поведение не изменилось. Затем вы делаете то же самое для опции XML, вводя новый метод ._serialize_to_xml () , перемещая в него реализацию и изменяя путь elif для его вызова.

В следующем примере показан код после рефакторинга:

  класс SongSerializer:
    def сериализовать (self, song, format):
        если format == 'JSON':
            вернуть себя._serialize_to_json (песня)
        elif format == 'XML':
            return self._serialize_to_xml (песня)
        еще:
            поднять ValueError (формат)

    def _serialize_to_json (я, песня):
        payload = {
            'id': song.song_id,
            'title': song.title,
            'исполнитель': song.artist
        }
        вернуть json.dumps (полезная нагрузка)

    def _serialize_to_xml (сам, песня):
        song_element = et.Element ('песня', attrib = {'id': song.song_id})
        title = et.SubElement (элемент_песни, 'название')
        заглавие.text = song.title
        artist = et.SubElement (song_element, 'исполнитель')
        artist.text = song.artist
        вернуть et.tostring (song_element, encoding = 'unicode')
  

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

Базовая реализация заводского метода

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

Чтобы завершить реализацию фабричного метода, вы добавляете новый метод ._get_serializer () , который принимает желаемый формат . Этот метод оценивает значение формата и возвращает соответствующую функцию сериализации:

  класс SongSerializer:
    def _get_serializer (сам, формат):
        если format == 'JSON':
            вернуть self._serialize_to_json
        elif format == 'XML':
            вернуть себя._serialize_to_xml
        еще:
            поднять ValueError (формат)
  

Примечание: Метод ._get_serializer () не вызывает конкретную реализацию, а просто возвращает сам объект функции.

Теперь вы можете изменить метод .serialize () объекта SongSerializer на использование ._get_serializer () для завершения реализации заводского метода. В следующем примере показан полный код:

  класс SongSerializer:
    def сериализовать (self, song, format):
        сериализатор = сам._get_serializer (формат)
        вернуть сериализатор (песня)

    def _get_serializer (сам, формат):
        если format == 'JSON':
            вернуть self._serialize_to_json
        elif format == 'XML':
            вернуть self._serialize_to_xml
        еще:
            поднять ValueError (формат)

    def _serialize_to_json (я, песня):
        payload = {
            'id': song.song_id,
            'title': song.title,
            'исполнитель': song.artist
        }
        вернуть json.dumps (полезная нагрузка)

    def _serialize_to_xml (сам, песня):
        song_element = et.Элемент ('песня', attrib = {'id': song.song_id})
        title = et. SubElement (элемент_песни, 'название')
        title.text = song.title
        artist = et.SubElement (song_element, 'исполнитель')
        artist.text = song.artist
        вернуть et.tostring (song_element, encoding = 'unicode')
  

Окончательная реализация показывает различные компоненты фабричного метода. Метод .serialize () — это код приложения, выполнение задачи которого зависит от интерфейса.

Это называется клиентский компонент шаблона.Определенный интерфейс упоминается как компонент продукта . В нашем случае продукт — это функция, которая принимает Song и возвращает строковое представление.

Методы ._serialize_to_json () и ._serialize_to_xml () являются конкретными реализациями продукта. Наконец, метод ._get_serializer () — это компонент creator . Создатель решает, какую конкретную реализацию использовать.

Поскольку вы начали с некоторого существующего кода, все компоненты Factory Method являются членами одного класса SongSerializer .

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

  класс SongSerializer:
    def сериализовать (self, song, format):
        сериализатор = get_serializer (формат)
        вернуть сериализатор (песня)


def get_serializer (формат):
    если format == 'JSON':
        вернуть _serialize_to_json
    elif format == 'XML':
        вернуть _serialize_to_xml
    еще:
        поднять ValueError (формат)


def _serialize_to_json (песня):
    payload = {
        'id': песня.song_id,
        'title': song.title,
        'исполнитель': song.artist
    }
    вернуть json.dumps (полезная нагрузка)


def _serialize_to_xml (песня):
    song_element = et.Element ('песня', attrib = {'id': song.song_id})
    title = et.SubElement (элемент_песни, 'название')
    title.text = song.title
    artist = et. SubElement (song_element, 'исполнитель')
    artist.text = song.artist
    вернуть et.tostring (song_element, encoding = 'unicode')
  

Примечание: Метод .serialize () в SongSerializer не использует параметр self .

Приведенное выше правило говорит нам, что он не должен быть частью класса. Это правильно, но вы имеете дело с существующим кодом.

Если вы удалите SongSerializer и измените метод .serialize () на функцию, вам придется изменить все места в приложении, которые используют SongSerializer , и заменить вызовы новой функции.

Если у вас не очень высокий процент покрытия кода модульными тестами, это не то изменение, которое вам следует делать.

Механика Factory Method всегда одинакова. Клиент ( SongSerializer.serialize () ) зависит от конкретной реализации интерфейса. Он запрашивает реализацию у компонента-создателя ( get_serializer () ), используя какой-то идентификатор ( формат ).

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

Вы можете выполнить тот же набор инструкций в интерактивном интерпретаторе Python, чтобы убедиться, что поведение приложения не изменилось:

  >>> импортировать serializer_demo как sd
>>> песня = сд.Песня ('1', 'Water of Love', 'Dire Straits')
>>> сериализатор = sd.SongSerializer ()

>>> serializer.serialize (песня, 'JSON')
'{"id": "1", "title": "Вода любви", "artist": "Dire Straits"}'

>>> serializer.serialize (песня, 'XML')
'   Dire Straits  '

>>> serializer.serialize (песня, 'YAML')
Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
  Файл "./serializer_demo.py ", строка 13, в сериализации
    сериализатор = get_serializer (формат)
  Файл "./serializer_demo.py", строка 23, в get_serializer
    поднять ValueError (формат)
ValueError: YAML
  

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

Признание возможностей использования заводского метода

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

Существует множество проблем, которые подходят под это описание, поэтому давайте рассмотрим несколько конкретных примеров.

Замена сложного логического кода: Сложные логические структуры в формате if / elif / else трудно поддерживать, потому что по мере изменения требований требуются новые логические пути.

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

Параметр, оцениваемый в условиях, становится параметром для идентификации конкретной реализации. Пример выше представляет эту ситуацию.

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

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

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

Приложение может позволить пользователю выбрать вариант, который идентифицирует конкретный алгоритм. Factory Method может предоставить конкретную реализацию алгоритма, основанного на этой опции.

Объединение аналогичных функций в общем интерфейсе: Следуя примеру обработки изображения, приложению необходимо применить фильтр к изображению.Конкретный используемый фильтр может быть определен пользователем, и Factory Method может предоставить конкретную реализацию фильтра.

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

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

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

Пример сериализации объекта

Основные требования для приведенного выше примера заключаются в том, что вы хотите сериализовать объекты Song в их представление string .Кажется, что приложение предоставляет функции, связанные с музыкой, поэтому вполне вероятно, что приложению потребуется сериализовать другие типы объектов, такие как Playlist или Album .

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

Реализация интерфейса может выглядеть примерно так:

  # в serializers.py

импортировать json
импортировать xml.etree.ElementTree как et

класс JsonSerializer:
    def __init __ (сам):
        self._current_object = Нет

    def start_object (self, object_name, object_id):
        self._current_object = {
            'id': object_id
        }

    def add_property (self, name, value):
        self._current_object [name] = значение

    def to_str (сам):
        вернуть json.dumps (self._current_object)


класс XmlSerializer:
    def __init __ (сам):
        self._element = Нет

    def start_object (self, object_name, object_id):
        self._element = et.Element (имя_объекта, attrib = {'id': object_id})

    def add_property (self, name, value):
        prop = et.SubElement (self._element, имя)
        prop.text = значение

    def to_str (сам):
        вернуть et.tostring (self._element, encoding = 'unicode')
  

Примечание: В приведенном выше примере не реализован полный интерфейс Serializer , но он должен быть достаточно хорош для наших целей и для демонстрации фабричного метода.

Интерфейс Serializer - абстрактное понятие из-за динамической природы языка Python. Статические языки, такие как Java или C #, требуют явного определения интерфейсов. В Python говорят, что любой объект, который предоставляет желаемые методы или функции, реализует интерфейс. В примере интерфейс Serializer определяется как объект, реализующий следующие методы или функции:

• .start_object (имя_объекта, идентификатор_объекта)
• .add_property (имя, значение)
• .to_str ()

Этот интерфейс реализован конкретными классами JsonSerializer и XmlSerializer .

В исходном примере использовался класс SongSerializer . Для нового приложения вы реализуете что-то более общее, например ObjectSerializer :

  # в serializers.py

класс ObjectSerializer:
    def сериализовать (самостоятельно, сериализуемый, формат):
        сериализатор = фабрика. get_serializer (формат)
        serializable.serialize (сериализатор)
        вернуть serializer.to_str ()
  

Давайте посмотрим на конкретную реализацию сериализуемого интерфейса в классе Song :

  # В songs.py

класс Песня:
    def __init __ (self, song_id, title, artist):
        self.song_id = song_id
        self.title = title
        self.artist = художник

    def serialize (self, сериализатор):
        serializer.start_object ('песня', self. song_id)
        serializer.add_property ('название', self.title)
        serializer.add_property ('исполнитель', сам.художник)
  

Класс Song реализует интерфейс Serializable , предоставляя метод .serialize (сериализатор) . В этом методе класс Song использует объект сериализатора для записи собственной информации без какого-либо знания формата.

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

До сих пор мы видели реализацию клиента ( ObjectSerializer ) и продукта (сериализатор ). Пришло время завершить реализацию Factory Method и предоставить создателя. Создателем в примере является переменная factory в ObjectSerializer.serialize () .

Фабричный метод как объектная фабрика

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

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

Вы можете увидеть базовый интерфейс SerializerFactory в реализации ObjectSerializer.сериализовать () . Метод использует factory.get_serializer (format) для извлечения сериализатора из фабрики объектов.

Теперь вы реализуете SerializerFactory для соответствия этому интерфейсу:

  # в serializers.py

класс SerializerFactory:
    def get_serializer (self, формат):
        если format == 'JSON':
            вернуть JsonSerializer ()
        elif format == 'XML':
            вернуть XmlSerializer ()
        еще:
            поднять ValueError (формат)


factory = SerializerFactory ()
  

Текущая реализация .get_serializer () — это то же самое, что вы использовали в исходном примере. Метод оценивает значение в формате и решает, какую конкретную реализацию создать и вернуть. Это относительно простое решение, которое позволяет нам проверить функциональность всех компонентов фабричного метода.

Давайте перейдем к интерактивному интерпретатору Python и посмотрим, как он работает:

  >>> импорт песен
>>> импортировать сериализаторы
>>> песня = песни.Песня ('1', 'Water of Love', 'Dire Straits')
>>> сериализатор = сериализаторы. ObjectSerializer ()

>>> serializer.serialize (песня, 'JSON')
'{"id": "1", "title": "Вода любви", "artist": "Dire Straits"}'

>>> serializer.serialize (песня, 'XML')
'   Dire Straits  '

>>> serializer.serialize (песня, 'YAML')
Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
  Файл "./serializers.py ", строка 39, в сериализации
    сериализатор = factory.get_serializer (формат)
  Файл "./serializers.py", строка 52, в get_serializer
    поднять ValueError (формат)
ValueError: YAML
  

Новый дизайн Factory Method позволяет приложению вводить новые функции путем добавления новых классов вместо изменения существующих. Вы можете сериализовать другие объекты, реализовав на них интерфейс Serializable . Вы можете поддерживать новые форматы, реализуя интерфейс Serializer в другом классе.

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

Поддержка дополнительных форматов

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

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

Идея состоит в том, чтобы предоставить метод в SerializerFactory , который регистрирует новую реализацию Serializer для формата, который мы хотим поддерживать:

  # в serializers.py

класс SerializerFactory:

    def __init __ (сам):
        self._creators = {}

    def register_format (сам, формат, создатель):
        self._creators [format] = создатель

    def get_serializer (self, формат):
        creator = self. _creators.get (формат)
        если не создатель:
            поднять ValueError (формат)
        вернуть создателя ()


factory = SerializerFactory ()
фабрика.register_format ('JSON', JsonSerializer)
factory.register_format ('XML', XmlSerializer)
  

Метод .register_format (формат, создатель) позволяет регистрировать новые форматы путем указания значения формата , используемого для идентификации формата и объекта создателя . Объект-создатель является именем класса конкретного сериализатора . Это возможно, потому что все классы Serializer предоставляют значение по умолчанию .__ init __ () для инициализации экземпляров.

Регистрационная информация хранится в словаре _creators . Метод .get_serializer () получает зарегистрированного создателя и создает желаемый объект. Если запрошенный формат не был зарегистрирован, возникает ValueError .

Теперь вы можете проверить гибкость дизайна, реализовав YamlSerializer и избавившись от надоедливой ValueError , которую вы видели ранее:

  # В yaml_serializer.ру

импортировать ямл
импортные сериализаторы

класс YamlSerializer (сериализаторы.JsonSerializer):
    def to_str (сам):
        вернуть yaml.dump (self._current_object)


serializers.factory.register_format ('YAML', YamlSerializer)
  

Примечание: Чтобы реализовать пример, вам необходимо установить PyYAML в своей среде, используя pip install PyYAML .

JSON и YAML — очень похожие форматы, поэтому вы можете повторно использовать большую часть реализации JsonSerializer и перезаписать .to_str () для завершения реализации. Затем формат регистрируется в объекте factory , чтобы сделать его доступным.

Давайте воспользуемся интерактивным интерпретатором Python, чтобы увидеть результаты:

  >>> импортные сериализаторы
>>> импорт песен
>>> импортировать yaml_serializer
>>> song = songs. Song ('1', 'Water of Love', 'Dire Straits').
>>> сериализатор = сериализаторы.ObjectSerializer ()

>>> print (сериализатор.сериализовать (песня, 'JSON'))
{"id": "1", "title": "Вода любви", "artist": "Dire Straits"}

>>> print (serializer.serialize (песня, 'XML'))
   Ужасные проливы  

>>> print (serializer.serialize (песня, 'YAML'))
{художник: Dire Straits, id: '1', название: Water of Love}
  

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

Фабрика объектов общего назначения

Реализация SerializerFactory — огромное улучшение по сравнению с исходным примером. Он обеспечивает большую гибкость для поддержки новых форматов и позволяет избежать изменения существующего кода.

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

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

Есть некоторые проблемы, связанные с предоставлением универсальной реализации Object Factory, и в следующих разделах вы рассмотрите эти проблемы и реализуете решение, которое можно повторно использовать в любой ситуации.

Не все объекты могут быть созданы равными

Самая большая проблема при реализации фабрики объектов общего назначения состоит в том, что не все объекты создаются одинаково.

Не все ситуации позволяют нам использовать значение по умолчанию .__ init __ () для создания и инициализации объектов. Важно, чтобы создатель, в данном случае Object Factory, возвращал полностью инициализированные объекты.

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

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

Примечание: Требования, которые я определяю для примера, приведены в целях иллюстрации и не отражают реальных требований, которые вам придется реализовать для интеграции с такими службами, как Pandora или Spotify.

Цель состоит в том, чтобы предоставить другой набор требований, который показывает проблемы реализации фабрики объектов общего назначения.

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

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

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

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

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

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

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

Создание отдельного объекта для обеспечения общего интерфейса

Создание каждого конкретного музыкального сервиса имеет свой набор требований. Это означает, что общий интерфейс инициализации для каждой реализации службы невозможен или не рекомендуется.

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

Начнем с конфигурации приложения:

  # В program.py

config = {
    'spotify_client_key': 'THE_SPOTIFY_CLIENT_KEY',
    'spotify_client_secret': 'THE_SPOTIFY_CLIENT_SECRET',
    'pandora_client_key': 'THE_PANDORA_CLIENT_KEY',
    'pandora_client_secret': 'THE_PANDORA_CLIENT_SECRET',
    'local_music_location': '/ usr / data / music'
}
  

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

Давайте посмотрим на реализацию SpotifyService и SpotifyServiceBuilder :

  # В music.py

класс SpotifyService:
    def __init __ (self, access_code):
        self._access_code = код_доступа

    def test_connection (сам):
        print (f'Доступ к Spotify с помощью {self._код доступа}')


класс SpotifyServiceBuilder:
    def __init __ (сам):
        self._instance = Нет

    def __call __ (self, spotify_client_key, spotify_client_secret, ** _ игнорируется):
        если не self._instance:
            access_code = self.authorize (
                spotify_client_key, spotify_client_secret)
            self._instance = SpotifyService (код_доступа)
        вернуть self._instance

    def authorize (self, key, secret):
        вернуть 'SPOTIFY_ACCESS_CODE'
  

Примечание: Интерфейс музыкальной службы определяет .test_connection () , которого должно хватить для демонстрационных целей.

Пример показывает SpotifyServiceBuilder , который реализует .__ call __ (spotify_client_key, spotify_client_secret, ** _ игнорируется) .

Этот метод используется для создания и инициализации конкретного SpotifyService . Он указывает обязательные параметры и игнорирует любые дополнительные параметры, предоставленные через ** _ игнорируется . После получения access_code он создает и возвращает экземпляр SpotifyService .

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

Давайте сделаем то же самое для Pandora:

  # В music.py

класс PandoraService:
    def __init __ (self, consumer_key, consumer_secret):
        self._key = consumer_key
        self._secret = consumer_secret

    def test_connection (сам):
        print (f'Доступ к Pandora с помощью {self. _key} и {self._secret} ')


класс PandoraServiceBuilder:
    def __init __ (сам):
        self._instance = Нет

    def __call __ (self, pandora_client_key, pandora_client_secret, ** _ игнорируется):
        если не self._instance:
            consumer_key, consumer_secret = self.authorize (
                pandora_client_key, pandora_client_secret)
            self._instance = Служба PandoraService (ключ_потребителя, секрет_потребителя)
        вернуть self._instance

    def authorize (self, key, secret):
        вернуть 'PANDORA_CONSUMER_KEY', 'PANDORA_CONSUMER_SECRET'
  

PandoraServiceBuilder реализует тот же интерфейс, но использует другие параметры и процессы для создания и инициализации PandoraService .Он также поддерживает экземпляр службы, поэтому авторизация происходит только один раз.

Наконец, давайте посмотрим на реализацию местной службы:

  # В music.py

класс LocalService:
    def __init __ (я, местоположение):
        self. _location = место

    def test_connection (сам):
        print (f'Доступ к местной музыке в {self._location} ')


def create_local_music_service (local_music_location, ** _ игнорируется):
    вернуть LocalService (local_music_location)
  

LocalService просто требует места, где хранится коллекция, для инициализации LocalService .

Новый экземпляр создается каждый раз, когда запрашивается услуга, поскольку нет медленного процесса авторизации. Требования проще, поэтому вам не нужен класс Builder . Вместо этого используется функция, возвращающая инициализированный LocalService . Эта функция соответствует интерфейсу методов .__ call __ () , реализованных в классах построителя.

Общий интерфейс для фабрики объектов

Фабрика объектов общего назначения ( ObjectFactory ) может использовать общий интерфейс Builder для создания всех видов объектов.Он предоставляет метод регистрации Builder на основе значения ключа и метод создания экземпляров конкретных объектов на основе ключа .

Давайте посмотрим на реализацию нашего общего ObjectFactory :

  # в object_factory.py

класс ObjectFactory:
    def __init __ (сам):
        self._builders = {}

    def register_builder (сам, ключ, строитель):
        self._builders [key] = строитель

    def create (self, key, ** kwargs):
        строитель = сам._builders.get (ключ)
        если не строитель:
            поднять ValueError (ключ)
        возвратный строитель (** kwargs)
  

Структура реализации ObjectFactory такая же, как и в SerializerFactory .

Разница в интерфейсе, который поддерживает создание любого типа объекта. Параметром построителя может быть любой объект, реализующий вызываемый интерфейс. Это означает, что Builder может быть функцией, классом или объектом, реализующим .__call __ () .

Метод .create () требует, чтобы дополнительные аргументы были указаны как аргументы ключевого слова. Это позволяет объектам Builder указывать необходимые им параметры и игнорировать остальные в произвольном порядке. Например, вы можете видеть, что create_local_music_service () указывает параметр local_music_location и игнорирует остальные.

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

  # В музыке.ру
import object_factory

# Пропуск других классов реализации, показанных выше

factory = object_factory.ObjectFactory ()
factory.register_builder ('SPOTIFY', SpotifyServiceBuilder ())
factory.register_builder ('PANDORA', PandoraServiceBuilder ())
factory.register_builder ('МЕСТНЫЙ', create_local_music_service)
  

Модуль music предоставляет экземпляр ObjectFactory через атрибут factory . Затем строители регистрируются в экземпляре.Для Spotify и Pandora вы регистрируете экземпляр соответствующего конструктора, но для локальной службы вы просто передаете функцию.

Напишем небольшую программу, демонстрирующую функциональность:

  # В program.py
импортировать музыку

config = {
    'spotify_client_key': 'THE_SPOTIFY_CLIENT_KEY',
    'spotify_client_secret': 'THE_SPOTIFY_CLIENT_SECRET',
    'pandora_client_key': 'THE_PANDORA_CLIENT_KEY',
    'pandora_client_secret': 'THE_PANDORA_CLIENT_SECRET',
    'local_music_location': '/ usr / data / music'
}

пандора = музыка.factory.create ('PANDORA', ** конфигурация)
pandora.test_connection ()

spotify = music.factory.create ('SPOTIFY', ** конфигурация)
spotify.test_connection ()

local = music.factory.create ('МЕСТНОЕ', ** конфигурация)
local.test_connection ()

pandora2 = music.services.get ('PANDORA', ** конфигурация)
print (f'id (pandora) == id (pandora2): {id (pandora) == id (pandora2)} ')

spotify2 = music.services.get ('SPOTIFY', ** конфигурация)
print (f'id (spotify) == id (spotify2): {id (spotify) == id (spotify2)} ')
  

Приложение определяет config словарь , представляющий конфигурацию приложения. Конфигурация используется в качестве аргументов ключевого слова для фабрики независимо от службы, к которой вы хотите получить доступ. Фабрика создает конкретную реализацию музыкального сервиса на основе указанного параметра key .

Теперь вы можете запустить нашу программу и посмотреть, как она работает:

  $ python program.py
Доступ к Pandora с помощью PANDORA_CONSUMER_KEY и PANDORA_CONSUMER_SECRET
Доступ к Spotify с помощью SPOTIFY_ACCESS_CODE
Доступ к локальной музыке в / usr / data / music
id (pandora) == id (pandora2): Верно
id (spotify) == id (spotify2): Верно
  

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

Специализированная фабрика объектов для улучшения читаемости кода

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

В приведенном выше примере показано, что для доступа к музыкальной службе вызывается music.factory.create () . Это может привести к путанице. Другие разработчики могут подумать, что каждый раз создается новый экземпляр, и решить, что им следует оставить экземпляр службы, чтобы избежать медленного процесса инициализации.

Вы знаете, что это не то, что происходит, потому что класс Builder сохраняет инициализированный экземпляр и возвращает его для последующих вызовов, но это не ясно из простого чтения кода.

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

В следующем примере показано, как специализировать ObjectFactory , предоставляя явный интерфейс для контекста приложения:

  # В music. py

класс MusicServiceProvider (object_factory.ObjectFactory):
    def get (self, service_id, ** kwargs):
        вернуть self.create (service_id, ** kwargs)


services = MusicServiceProvider ()
services.register_builder ('SPOTIFY', SpotifyServiceBuilder ())
services.register_builder ('PANDORA', PandoraServiceBuilder ())
Сервисы.register_builder ('МЕСТНЫЙ', create_local_music_service)
  

Вы получаете MusicServiceProvider из ObjectFactory и предоставляете новый метод .get (service_id, ** kwargs) .

Этот метод вызывает общий .create (key, ** kwargs) , поэтому поведение остается прежним, но код лучше читается в контексте нашего приложения. Вы также переименовали предыдущую переменную factory в services и инициализировали ее как MusicServiceProvider .

Как видите, обновленный код приложения теперь читается намного лучше:

  импорт музыки

config = {
    'spotify_client_key': 'THE_SPOTIFY_CLIENT_KEY',
    'spotify_client_secret': 'THE_SPOTIFY_CLIENT_SECRET',
    'pandora_client_key': 'THE_PANDORA_CLIENT_KEY',
    'pandora_client_secret': 'THE_PANDORA_CLIENT_SECRET',
    'local_music_location': '/ usr / data / music'
}

pandora = music. services.get ('ПАНДОРА', ** конфигурация)
pandora.test_connection ()
spotify = music.services.get ('SPOTIFY', ** конфигурация)
спотифицируйте.test_connection ()
local = music.services.get ('МЕСТНОЕ', ** конфигурация)
local.test_connection ()

pandora2 = music.services.get ('PANDORA', ** конфигурация)
print (f'id (pandora) == id (pandora2): {id (pandora) == id (pandora2)} ')

spotify2 = music.services.get ('SPOTIFY', ** конфигурация)
print (f'id (spotify) == id (spotify2): {id (spotify) == id (spotify2)} ')
  

Запуск программы показывает, что поведение не изменилось:

  $ python program.py
Доступ к Pandora с помощью PANDORA_CONSUMER_KEY и PANDORA_CONSUMER_SECRET
Доступ к Spotify с помощью SPOTIFY_ACCESS_CODE
Доступ к локальной музыке в / usr / data / music
id (pandora) == id (pandora2): Верно
id (spotify) == id (spotify2): Верно
  

Заключение

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

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

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

Из этой статьи вы узнали:

• Что такое шаблон проектирования Factory Method и каковы его компоненты
• Как провести рефакторинг существующего кода для использования заводского метода
• Ситуации, в которых следует использовать заводской метод
• Как фабрики объектов обеспечивают большую гибкость для реализации фабричного метода
• Как реализовать объектную фабрику общего назначения и ее проблемы
• Как специализировать общее решение, чтобы обеспечить лучший контекст

Дополнительная литература

Если вы хотите узнать больше о фабричном методе и других шаблонах проектирования, я рекомендую Design Patterns: Elements of Reusable Object-Oriented Software от GoF, который является отличным справочником по широко распространенным шаблонам проектирования.