ок.. вернемся взад: с какой проблемой мы столкнулись, решив переопределять шаблонные методы, но этого делать низя, потому мы переопределили сериализаторы? честногря, я даже не знаю с какой целью интересуюсь, потому что башка и так на работе забилась, а ее еще туда чтото пропихиваю.. может, думаю, клин клином..
ок.. вернемся взад: с какой проблемой мы столкнулись, решив переопределять шаблонные методы, но этого делать низя, потому мы переопределили сериализаторы? честногря, я даже не знаю с какой целью интересуюсь, потому что башка и так на работе забилась, а ее еще туда чтото пропихиваю.. может, думаю, клин клином..
вообще вопрос был изначально про "почему нельзя переопределять шаблонные методы в классах" ответ: потому что это влечёт за собой лавинообразное раздувание бинарника
зачем может быть нужно переопределять шаблонный метод? например в задаче где хочется подменять поведение шаблонного метода в runtime
в моей конкретной задаче некий объект пишет данные (не логи, а целевые данные) в один сериализатор (журнал csv), а в случае запроса из вэба в другой (json)
Теоретически они могли бы эти данные возвращать, а код уже сам их мог решить как сериализировать
итак, у нас есть объект, который формирует структуру данных {BeginScope, IntValue, StringValue, EndScope} 1. этот объект получает ISerializator { beginScope... } и сам дерагает его методы. тогда все сериализаторы наследуются от этого интерфейса 2. любой независимый сериализатор может опрашивать Формирователь (знает его АПИ) и пихать данные как хочет. сериализаторы ваще не связаны какими либо зависимостями или интерфейсами