#design-patterns
#шаблоны проектирования
Вопрос:
В моем текущем проекте есть классы, наследуемые от абстрактного IHaveHadoopConfig
, который в своем getConf
выполняет ленивую инициализацию конфигурации с параметрами, специфичными для этого класса, а затем он сохраняется в переменной-члене conf
.
Я не хочу наследовать от этого класса, я скорее наследую от других функциональных классов (copyTask, doStuffTask и т. Д.) И никакого множественного наследования для меня, И я хочу другой класс обслуживания, который будет вводить конфигурацию в мои классы.
Но это означает, что я должен дублировать код для ленивого инициализации у всех потребителей этой услуги, нет?
Комментарии:
1. Почему классы задач не могут наследовать от абстрактных?
2. потому что для этого потребуется множественное наследование. Я также не считаю, что это правильная иерархия, бизнес конфигурации — это просто сервис, дело не в том, что
CopyHadoopFilesTask
is-aINeedHadoopConfigTask
, это aCopyTask
, которому нужна какая-то служба конфигурации hadoop3. Возможно, вы могли бы адаптировать свой код для использования шаблона поиска служб.