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