Передача параметров компоновщику с помощью подкомпонентов компонентов - PullRequest
Новая
       18

Передача параметров компоновщику с помощью подкомпонентов компонентов

0 голосов
/ 31 января 2019

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

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

Подробности - я использую дизайн компоновщика шаблон, где BuilderA содержит подструктуры BuilderB() и BuilderC.Моя текущая мысль о дизайне состояла в том, чтобы передать один и тот же набор аргументов ключевого слова каждому вспомогательному конструктору: 

class BuilderA():
    def __init__(self):
        self.builder_b = BuilderB()
        self.builder_c = BuilderC()

    def build(self, **build_parameters):
        artifact_b = self.builder_b.build(**build_parameters)
        artifact_c = self.builder_c.build(**build_parameters)
        # ... do something to create BuilderA's artifact ...

У каждого вспомогательного сборщика есть различные параметры ключевого слова: 

class BuilderB():
    def build(self, param_1=None, param_2=None, **ignored_kwds):
        # ...

class BuilderC():
    def build(self, param_3=None, param_4=None, **ignored_kwds):
        # ...

В качестве альтернативы API , BuilderA может выглядеть следующим образом: 

class BuilderA():

    def build(self, builder_b_parameters={}, builder_c_parameters={}):
        artifact_b = self.builder_b.build(**builder_b_parameters)
        artifact_c = self.builder_c.build(**builder_c_parameters)
        # ... do something to create BuilderA's artifact ...

Является ли один из этих проектов, как правило, более приемлемым, чем другой?Или есть другой вариант, который я не рассмотрел?

Мысли - Первый дизайн более чистый, но мешает BuilderB и BuilderC делиться именами ключевых слов.Кроме того, он требует, чтобы каждый из их сборщиков включал **ignored_kwds в свое объявление метода сборки.Опасность такого подхода заключается в том, что если пользователь неправильно введет аргумент ключевого слова, то может произойти непредвиденное поведение без ошибок.С другой стороны, второй дизайн делает интерфейс к BuilderA более громоздким, но решает вышеупомянутые проблемы.

1 Ответ

0 голосов
/ 01 февраля 2019

Конечно, узкие вещи.Не позволяйте своему строителю, специализирующемуся на артефактах, «знать» обо всем мире;это определенно нанесет удар тебе в ответ.

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

Делайте вещи намного проще за счет явной маркировки.

...