Комментарии 4
Следующим этапом заводятся классы типа GenericContext (или NVPL — name-value pair list), и все описанные классы делаются Configurable из GenericContext-а. Потом пишутся адаптеры на GenericContext из XML и JSON. В результате, получается приложение с функционалом, определяемым конфигурацией. Это очень мощная и красивая вещь, но надо понимать, что в какой-то момент конфигурация становится этаким специфичным (в клинических случаях — тьюринг-полным) языком программирования, описывающим существенные свойства классов и их взаимоотношения. Если это не пугает и оправдано сложностью решаемой задачи — почему бы и нет? На Java можно посмотреть в сторону Spring, где через XML-файл (или аннотации) можно вшивать одни Beans (экземпляры классов) в другие. Так вот, людей которые могли бы («с нуля», не с шаблона или предыдущей версии) написать конфиги spring/hibernate/maven — оказывается, не так и много! :-)
но надо понимать, что в какой-то момент конфигурация становится этаким специфичным (в клинических случаях — тьюринг-полным) языком программированияЯ думал над этой проблемой, и с одной стороны можно декомпозировать классы на более простые, дабы для конструирования каждого отдельного не приходилось учитывать десятки, или даже сотни конфигов, а с другой — можно ограничивать спектр решаемых задач, не пытаясь при помощи конвейера создавать классы, которые руками описать будет все же быстрее. Или, оптимально, можно простые параметры описывать в виде конфигов, с последующей интерпретацией, а более комплексные — уже ручками(Не пишу на java, но есть ощущение что описанный Вами java beans так и делает).
А зачем Вы в данной ситуации используете виртуалное наследование?
Классы, которые виртуально наследуют ITransport, финализированы и не смогут далее учавтстовать в иерархии наследования.
Классы, которые виртуально наследуют ITransport, финализированы и не смогут далее учавтстовать в иерархии наследования.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация создания объектов при помощи конвейера