Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Основных проблем две:
КЛ>
КЛ>Изменение, добавление или удаление отдельного атрибута приводит к реорганизации иерархии.
КЛ>Злоупотребление оператором преобразования типов (dynamic_cast в C++ или as в C#) и, как результат, нарушение LSP.
КЛ>
КЛ>Более детально обо всех этих проблемах написано в одной из моих статей.
КЛ>При использовании интерфейсов возникает еще и третья проблема — изменение прототипа одного из методов интерфейса или добавление метода в интерфейс неминуемо приводит к необходимости изменения во всех реализациях. Это, конечно, характерно для любого интерфейса (например, Win32 API или OpenGL). Но проблема проявляется довольно часто, когда интерфейс строится путем "фильтрации" — когда общие для всех классов свойства выносятся в базовые классы (интерфейсы). Т.е. когда анализируются атрибуты и сходные атрибуты группируются в базовые классы (или интерфейсы).
Кирилл, в том что вы говорите про решения Гради Буча и сейчас пытаетесь сказать про решения WolfHound-а просматривается одна и та же красная нить: мол отгребете вы, ребята, по полной, когда будете вынуждены свои иерархии расширять для поддержки новых требований.
И забываете простую штуку -- для того, чтобы появились эти самые новые требования, нужно здесь и сейчас получить работающее решение той конкретной задачи, которая была поставлена. Не больше, не меньше. Были в задаче Гради Буча именно такие датчики, он их объеденил в иерархию так, чтобы было не сложно и
чтобы работало. Макаронный эфект там наблюдается, на вскидку, только в DisplayManager::display и все. Отказ от этого макаронного кода привел бы, скажем, к реализации Visitor-ов и усложнения датчиков. Т.е. решение Буча подчиняется простой идее: вовремя сделать минимально необходимый и минимально сложный код для решения конкретной задачи. Все остальные проблемы должны решаться по мере их поступления.
Вы же со своим стремлением показать, что все в будущем будет плохо и что лучше сразу сделать идеальное решение, являетесь, к сожалению, ярким примером "русских программистов". Вроде как "мы будет долго запрягать, выдумывая идеальное решение, зато потом быстро доедем".
Цитата для иллюстрации:
Мне как-то рассказывали на фирме Sun, что когда в 1995 году оставалось три дня до сдачи «Соляриса», им нужен был тест для Фортран-транслятора. Послали в Новосибирск заказ (у Sun была там своя группа) — сделать за два дня тест. Через неделю получили ответ, что через месяц будет замечательный тест на все случаи жизни.
Вообще-то говоря, перепроектирование и изменение иерархий -- это совершенно нормальный процесс разработки ПО. Ничего страшного в нем нет. Создавать сразу устойчивые к изменению требований системы возможно, вероятно, только для тчательно изученных предметных областей, имея за плечами большое количество аналогичных проектов. Только не всегда это возможно. Хотя бы потому, что всем нам время от времени приходится менять сферу деятельности. И учиться чему-то с нуля, при этом от нас требуется создание работающих систем в конкретные сроки по вполне конкретным требованиям.
Кстати, отсылки к вашим предыдущим статьям выглядят как-то несолидно. Пора бы уже такой же толмуд по проектированию идеальных систем написать, как Буч по ОО проектированию. Вот ссылки на него будут выглядеть гораздо солиднее.
