Правильный шаблон для настройки объектов, созданных Factory

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

Проще говоря, у вас есть:

  • Прототип объекта, предоставляющий интерфейс (назовем его абстрактным ядром);
  • Конкретные ядра, реализующие вышеупомянутый интерфейс различными способами;
  • Конкретное ядро ​​Factory;
  • Другой объект Foo, в котором хранится указатель на абстрактное ядро, как возвращается Factory.

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

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

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

Заранее спасибо!

ПРИМЕЧАНИЕ. В моей текущей реализации нет ядра Factory. Я поместил конкретный тип ядра в качестве шаблона Foo и задал ядро ​​как открытый элемент, который позволяет мне настроить ядро ​​после объявления и до начала обработки.

0
nl ja de

2 ответы

Если кусок кода знает, с каким конкретным ядром он работает, он должен иметь указатель на конкретный конкретный тип ядра. Если это не так, он не может получить доступ к своим конкретным параметрам (но может получить доступ ко всем параметрам в общем виде, как это предложил @Jaywalker).

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

I have very limited info about your design, but it looks like you have several concrete kernel types, a separate builder for each type, and a separate configurator for each type. Packing all the builders into a Factory is problematic, as there's no clean and elegant way to forward concrete kernel types to their respective configurators (without things like *_cast<> or double dispatch). There are at least two ways to solve this and still have a Factory:

  1. Объедините каждый строитель с соответствующим конфигуратором и упакуйте все пачки в Factory, который выдает настроенные ядра.
  2. Объедините каждое ядро ​​с его конфигуратором и создайте фабрику, производящую эти пакеты (таким образом, ядро ​​может быть настроено любое количество раз в течение его жизненного цикла).
1
добавлено
В этом случае, следуя вашим комментариям и Jaywalker's, я думаю, что для общего решения будет запутывать код более, чем сделать его более чистым, так как пока у меня есть только несколько конкретных реализаций ядра, и ожидается, что он не станет намного больше. Один комментарий, хотя, относительно вашего сообщения и Jaywalk; Foo не знает о параметрах ядра, только о интерфейсе прототипа, но ядро ​​требует предварительной настройки.
добавлено автор Sheljohn, источник
Не может ли ядро ​​«читать» конфигурацию из другого места, если Foo не нужно знать об этих параметрах?
добавлено автор Jaywalker, источник

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

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

virtual bool setParameter (const string &key, const string &value) = 0;
virtual string getParameter (const string &key) = 0;
1
добавлено
Спасибо за ваш ответ, этого я и боялся. Основная проблема, связанная с установщиками/геттерами для определения ключевых значений ключей, заключается в том, что для реализации этого параметра требуется больно, чтобы учесть любой тип параметра.
добавлено автор Sheljohn, источник
pro.cxx
pro.cxx
3 049 участник(ов)

C/C++ chat 0. Простые вопросы, лабы и о IDE — в чат новичков @supapro 1. Не хамим, не переходим на личности, не вбрасываем утверждения без доказательств 2. No Ads, offtop, flood Объявления о вакансиях и евенты - в лс @AlexFails https://t.me/ProCxx/259155

supapro.cxx
supapro.cxx
1 925 участник(ов)

Чат для тех, кто немного знает C++, простые вопросы по реализации, синтаксису и ide – сюда, а для другого есть: /Главный чат по серьезным вопросам — @ProCxx /Чат по обсуждению всего — @fludpac

C++ Russia
C++ Russia
384 участник(ов)

Сообщество разработчиков C++ в Telegram.

cxx.Дискуссионная
cxx.Дискуссионная
298 участник(ов)

это не двач, общайтесь вежливо; разговор на почти любые темы; Не согласны с баном? В лс @AlexFails, @ivario

C++ для маленьких и тупых
C++ для маленьких и тупых
105 участник(ов)

Лоу левел (по среднему IQ участников) чатик ExtremeCode @extremecode Флудилка @extremecode_rest