Сообщение Re: Реализация полиморфизма от 06.05.2016 12:42
Изменено 09.05.2016 21:47 Current
Здравствуйте, RikkiTikkiTavi, Вы писали:
RTT>Добрый день!
RTT>Хотелось бы освежить себе теорию по части реализации полиморфного поведения классов. А именно, какие паттерны призваны решать нижеописанную (в общем-то, стандартную) задачу:
RTT>
RTT>Есть некий иерархический набор сущностей, воплощенный в коде в виде иерархии классов, инкапсулирующий свойства и доступ к ним. (Скажем, автомобили: грузовые, легковые, волга, камаз,...). Размер иерархии не тривиальный и насчитывает порядка 20 классов. Объекты используются всегда только конечных классов, т.е. все родители только для обобщения.
RTT>Есть несколько подсистем, требующий от сущностей полиморфного поведения. Т.е., каждая подсистема принимает базовый интерфейс, состоящий из полиморфных методов, специфически реализованных для каждого класса иерархии. Размер кода реализации может быть достаточно объёмен и требовать инклуда интерфейса конкретных подсистем.
RTT>
RTT>Какие крайние варианты реализации полиморфизма возможны:
RTT>
RTT>Классы, описывающие сущности, непосредственно сами реализуют интерфейсы для каждой из подсистем. Достоинство: все в одном месте, нет дополнительных классов. Недостаток: жуткая мешанина (мы называем это "колхоз"), жуткая связность.
RTT>Реализацию интерфейса для каждой подсистемы можно вынести в отдельный класс. Поскольку наличествует иерархия, и довольно существенная, неизбежно возникает соответствующая иерархия классов реализации. И так для каждой подсистемы. Достоинство: уменьшенная связность, реализация для каждой подсистемы в отдельном файле, уменьшив инклуды сторонних тулкитов.
RTT>Реализация интерфейса в отдельном файле через свитчи по типу сущности. Достоинства: несколько проще предыдущего варианта и подходит для относительно просто кода реализации расширения, код для данной подсистемы в одном месте для разных классов.
RTT>
RTT>Собсно, у нас по факту используются и этих способа, и разные степени микса. По сути, определяющим фактором у меня явился размер кода реализации под каждую подсистему и его связка со сторонними библиотеками.
RTT>А что говорит теория? Какие паттерны перечитать?
а чем 2 вариант плох?
RTT>Добрый день!
RTT>Хотелось бы освежить себе теорию по части реализации полиморфного поведения классов. А именно, какие паттерны призваны решать нижеописанную (в общем-то, стандартную) задачу:
RTT>
RTT>Есть некий иерархический набор сущностей, воплощенный в коде в виде иерархии классов, инкапсулирующий свойства и доступ к ним. (Скажем, автомобили: грузовые, легковые, волга, камаз,...). Размер иерархии не тривиальный и насчитывает порядка 20 классов. Объекты используются всегда только конечных классов, т.е. все родители только для обобщения.
RTT>Есть несколько подсистем, требующий от сущностей полиморфного поведения. Т.е., каждая подсистема принимает базовый интерфейс, состоящий из полиморфных методов, специфически реализованных для каждого класса иерархии. Размер кода реализации может быть достаточно объёмен и требовать инклуда интерфейса конкретных подсистем.
RTT>
RTT>Какие крайние варианты реализации полиморфизма возможны:
RTT>
RTT>Классы, описывающие сущности, непосредственно сами реализуют интерфейсы для каждой из подсистем. Достоинство: все в одном месте, нет дополнительных классов. Недостаток: жуткая мешанина (мы называем это "колхоз"), жуткая связность.
RTT>Реализацию интерфейса для каждой подсистемы можно вынести в отдельный класс. Поскольку наличествует иерархия, и довольно существенная, неизбежно возникает соответствующая иерархия классов реализации. И так для каждой подсистемы. Достоинство: уменьшенная связность, реализация для каждой подсистемы в отдельном файле, уменьшив инклуды сторонних тулкитов.
RTT>Реализация интерфейса в отдельном файле через свитчи по типу сущности. Достоинства: несколько проще предыдущего варианта и подходит для относительно просто кода реализации расширения, код для данной подсистемы в одном месте для разных классов.
RTT>
RTT>Собсно, у нас по факту используются и этих способа, и разные степени микса. По сути, определяющим фактором у меня явился размер кода реализации под каждую подсистему и его связка со сторонними библиотеками.
RTT>А что говорит теория? Какие паттерны перечитать?
а чем 2 вариант плох?
Re: Реализация полиморфизма
RTT>Реализацию интерфейса для каждой подсистемы можно вынести в отдельный класс. Поскольку наличествует иерархия, и довольно существенная, неизбежно возникает соответствующая иерархия классов реализации. И так для каждой подсистемы. Достоинство: уменьшенная связность, реализация для каждой подсистемы в отдельном файле, уменьшив инклуды сторонних тулкитов.
а чем 2 вариант плох?
а чем 2 вариант плох?