Вот есть предположим некоторое множество содержащее разнородные элементы.
Для меня естественно сделать интерфейс IElement с методом GetElementType и в зависимости от того, что вернул метод приводить объект к соответствующему типу (dynamic_cast, QueryInterface или as не суть важно).
Но в Microsoft судя по всему считают по-другому. Уже второй раз сталкиваюсь с идеей, что интерфейс IElement должен содержать не только GetElementType, но и все методы которые только могут понадобится для всех возможных типов элемента.
Примеры:
Интерфейс IDiaSymbol — содержит 94 метода из которых для каждого конкретного типа символа используется 5-8, о чём любезно сообщается в документации.
Интерфейс IVsHierarchy — поддерживает 66 свойств добрая половина которых имеет смысл только для корневого узла, да и оставшаяся половина тоже не всегда целиком используется, о чём любезно сообщается в документации.
Вопрос прост — как на самом деле лучше?
Первый пример — интерфейс к Си++ компилятору, второй — к самой студии.
Не думаю, чтобы на этих направлениях работали второсортные программисты.
Может я не вижу чего-то?
Здравствуйте, adontz, Вы писали:
A>Не думаю, чтобы на этих направлениях работали второсортные программисты. A>Может я не вижу чего-то?
Их было слишком много. Надо же их чем-то занимать?
С уважением, Gleb.
PS: там ничем вроде lex\yacc или antlr не попахивает?
Я посмотрел интерфейс IDiaSymbol и у меня возникла замечательная догадки.
1. Если говорить о самом Debug Interface API — то это очень замечательный объем метаданных. Возможно решили не плодить дополнительно.(наиболее вероятно)
2. Объект интенсивно используется, и поэтому вместо того чтобы каждый раз его создавать, его пулят без состояния и затем натравливают на готовые данные.
3. Microsoft решила показать всем грабли, чтобы никто на них в будуйщем не наступал.
Во-первых, DIA SDK это фактически интерфейс к самопальной БД и всё там упирается в скорость винчестера. Повторные чтения одних и тех же значений выполняются за одинаковое время — особненно там ничего не пулится и не оптимизируется.
Во-вторых, мы несколько отвлеклись. Вопрос ведь не в том, почему какой-то конкретный интерфейс именно такой какой он есть, а в том, есть ли у описанного метода пихания всех методов в один интерфейс какие-то скрытые преимущества (потому что открытых я не вижу)?
Здравствуйте, adontz, Вы писали:
A>Вопрос ведь не в том, почему какой-то конкретный интерфейс именно такой какой он есть, а в том, есть ли у описанного метода пихания всех методов в один интерфейс какие-то скрытые преимущества?
Ну, на первый взгляд, данное решение впрямую противоречит Interface Segregation Principle, что однозначно плохо.
CLIENTS SHOULD NOT BE FORCED TO DEPEND UPON INTERFACES THAT THEY DO NOT USE
Однако, имхо, тут нужно обозначить одну важную оговорку — речь идет о "клиентах", прецеденты работы которых известны заранее.
К сожалению, применительно к случаю "абстрактных деревьев", ясно что их проектировщики чаще всего принципиально не знают от том, как эти деревья потом будут использованы. Соответственно, нет особых причин почему бы, для простоты, не запихнуть все аспекты узлов в один "толстый" интерфейс.
Вариант с dynamic_cast/QI/as, мне кажется, не дает тут какого-то кардинального улучшения. Всё равно ведь непосредственно работающему с деревом коду будут доступны все возможные подинтерфейсы. Разве что перекомпиляция, в случае c++, побыстрее пойдет, но за это приходится частично поступаться статической типизацией — не факт, что оно того стоит.
Наверное иногда удобнее (и честнее) бывает вообще отказаться от объектности узлов этого дерева. Хранить в нем просто структуры, а ООП изображать уже на клиентской стороне, с помощью Adaptor-ов. Всё равно ведь (из моего личного опыта), если уж связался с "абстрактными деревьями", то при их использовании какие-нибудь Adaptor'ы/OR-Mapper'е почти наверняка понадобятся
Кстати, в DIA, похоже именно по этому пути и пошли. IDiaSymbol — объект практически без поведения. Из 94-х методов у него 93 read-only свойства, а 94-ый это findChildren
Вообще же, конечно, самым правильным тут было бы использовать что-то в духе паттерна Visitor, но, к сожалению, это не всегда удобно
Здравствуйте, adontz, Вы писали:
A>Может я не вижу чего-то?
Наверно, это пагубное влияние динамических языков на мышление разработчиков.
Или тонкая идеологическая диверсия, чтобы убедить всех, что "ничего ваша проверка типов во время компиляции не стоит"
Здравствуйте, adontz, Вы писали:
A>Интерфейс IVsHierarchy — поддерживает 66 свойств добрая половина которых имеет смысл только для корневого узла, да и оставшаяся половина тоже не всегда целиком используется, о чём любезно сообщается в документации.
Ну о нем особый разговор. Сам интерфейс такого количества свойств не содержит, доступ к свойствам сделан через хитрый метод. Мне кажется они сделали так ради того, чтобы свободно, без модификации интерфейса, расширять набор свойств, как со стороны студии, так и со стороны разработчика конкретного типа проекта.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ну о нем особый разговор. Сам интерфейс такого количества свойств не содержит, доступ к свойствам сделан через хитрый метод.
Это технические подробности .
Вобщем как я понял никакой великой идеи за подобным дизайном не стоит.
Здравствуйте, adontz, Вы писали:
AVK>>Ну о нем особый разговор. Сам интерфейс такого количества свойств не содержит, доступ к свойствам сделан через хитрый метод. A>Это технические подробности .
Это скорее всего как раз и является причиной такого интерфейса.
A>Вобщем как я понял никакой великой идеи за подобным дизайном не стоит.
Ну по большому счету это борьба с СОМ. Хотя и в фреймворке иногда перлы проскакивают вроде IBindingList. Вобще МС в случае интерфейсных моделей регулярно выдает потрясающе некачественную архитектуру. Борются со сторонними реализациями своих механик?
Здравствуйте, AndrewVK, Вы писали:
A>>И не говори! Я уже который день оборачиваю IVsHierarchy во что-то приличное, а он всё никак не обернётся AVK>С какой стороны обрачиваешь? Изнутри или снаружи?
Пытаюсь снаружи. Хотел изнутри, но то ли опыт Си++ мешает, то ли на C# руки кривые, но когда оборачиваю изнутри, выходит сплошной рефлекшн.
