Здравствуйте, WolfHound, Вы писали:
КЛ>>Мой ответ: Да, именно такой дизайн я не считаю удачным. Он, безусловно, имеет право на существование, как и всякая модель, но, к сожалению, приводит к серьезным проблемам при сопровождении.
WH>Интересно к каким?
Основных проблем две:
Изменение, добавление или удаление отдельного атрибута приводит к реорганизации иерархии.
Злоупотребление оператором преобразования типов (dynamic_cast в C++ или as в C#) и, как результат, нарушение LSP.
Более детально обо всех этих проблемах написано в одной из моих
статей.
При использовании интерфейсов возникает еще и третья проблема — изменение прототипа одного из методов интерфейса или добавление метода в интерфейс неминуемо приводит к необходимости изменения во всех реализациях. Это, конечно, характерно для любого интерфейса (например, Win32 API или OpenGL). Но проблема проявляется довольно часто, когда интерфейс строится путем "фильтрации" — когда общие для всех классов свойства выносятся в базовые классы (интерфейсы). Т.е. когда анализируются атрибуты и сходные атрибуты группируются в базовые классы (или интерфейсы).
Все эти проблемы я могу показать и на Вашем примере. Но тогда мне нужно знать, какие операции объявлены в каждом из интерфейсов, чтобы не выдумывать их из головы.
WH>Эти интерфейсы являются моделью метаданных.
Это-то мне понятно. Но я спрашивал немного о другом. На всякий случай, переформулирую вопросы:
Какие обязанности существуют у этой иерархии (целиком)?
Какие обязанности существуют у отдельного интерфейса или класса иерархии? У IElementBase, IPropertyBase, IElement, IAttachedElement, IProperty, IAttachedProperty и т.д.?
Из Вашиз ответов я понял, что обязанности таковы:
Восстановление формы из сериализованного представления.
Сериализация формы.
Редактирование формы (?).
Иное?
