Оберон-технология: особенности и перспективы |
Тематика обсуждения: Оберон-технология. Особенности, перспективы, практическое применение.
Всего в теме 6256 сообщений
Добавить свое сообщение
Отслеживать это обсуждение Обсуждение из раздела Школа ОБЕРОНА
№ 4756 17-05-2007 01:15 | |
Для орловцев
Что-то я в последнее время через раз (или ещё реже) в форум могу входить.
После ввода пароля или выкидывает опять в то же окно, или переходит на список форумов, но без успешного входа...
"Прошу принять меры!"(с) :о)
№ 4755 17-05-2007 01:12 | |
По мотивам выступлений С.Перовского насчет хорошо выстроенных деревьев наследования vs "шины" и т.п. (интерпретация грубая, прошу сильно не бить; кстати, двойная диспетчеризация -- неплохой термин, зря, пожалуй, С.Губанов ругается -- какое нам тут дело до COM):
Аморфность "шины" позволяет начать экспериментировать (и даже решать задачи, что, кстати, у меня важно), когда еще нет понимания для выстраивания дерева. Где понимание-то взять-то? Только из опыта.
А дерево вырастает как раз из борьбы за сохранение контроля в условиях нарастающей энтропии при работе с шиной -- из конкретного разглядывания ветвей всяких WITH внутри разных HandleMsg, выделения общих процедур, вызывающихся (ну в точности "двойная диспетчеризация") из этих ветвей и сначала скрытых в модуле, потом выводимых "наружу" и закрепляемых в базовых ABSTRACT-интерфейсах... так примерно.
Когда код налицо, да еще видно как что работает, выделять куски будущего дерева (или леса) гораздо проще, чем априорно. Априорно некоторые важные вещи хрен заране вообразишь.
№ 4754 17-05-2007 01:10 | |
Ответ на »сообщение 4751« (Сергей Перовский)
___________________________
Сторонники множественного наследования пытаются получить систему на все случаи жизни, что приводит к черезвычайному усложнению системы в целом и для каждого частного случая.
Стоп. Это ВЫ так думаете, что они пытаются так делать! В действительности, они, всего лишь, ИСПОЛЬЗУЯ НАЛИЧНЫЕ ЯЗЫКОВЫЕ СРЕДСТВА, пытаются отобразить на совокупность программных сущностей свойства сущностей модельных. Другое дело, что давая некоторые преимущества, множественное наследование (в инкарнации Си++) не избавляет от кучи недоразумений и "ступора выбора чего имелось в виду". :о)
Наследование по интерфейсам, конечно же, более гибче в плане описательном моделей. Да и в Си-шарпе есть средства для "разруливания неоднозначностей".
Но я опять повторюсь (это - моё мнение, а. потому, - "единственно правильное"! :о))) ), что не столь важна констатация поддержки неким "классом" набора "интерфейсов" В МЕСТЕ ОБЪЯВЛЕНИЯ этого "класса", сколько - проверка (статическая или динамическая) правомочности вызова некоей функциональности в месте использования экземпляра этого "класса". Конечно, лучше, если - статика, во время компиляции. И не нужно загромождать синтаксическими конструкциями в местах "объявлений". А вывод о правомочности вызова желательно иметь на основании вывода типа, максимально автоматизируя процесс и разгружая программиста.
№ 4753 16-05-2007 12:39 | |
№ 4752 16-05-2007 10:52 | |
Ответ на »сообщение 4749« (Владимир Лось)
___________________________
>>>Ну так это - HAS-A - туту проблем никаких - "граничные условия" зачастую определяются прямо из механистической природы "отношений" составных частей целого...
Да нет, тут та же холера...
Корабль можно делить по секциям постройки, по подсистемам, по палубам и еще прорвой разных способов. И все будут правильными. В каком то смысле.
Опять без понимания "для чего" нам не обойтись.
>>>не могут они быть "надстройкой" или "налогаться". Их просто "имеют в вдиду" и "учитывают"...
Формально это, конечно, так, но для конкретного человека, некоторое представление объекта всегда превалирует над остальными. Именно так я понял рассуждения о надстройке.
№ 4751 16-05-2007 10:45 | |
Ответ на »сообщение 4749« (Владимир Лось)
___________________________
>>>А если сущность имеет признаки, позволяющие ставить её в РАЗНЫЕ деревья "частных случаев" (IS-A)? Это к вопросу о конфликте между сторонниками и противниками одиночного/множественного наследования
Почему "если"? Всегда имеет. И только очертив проблемную область мы можем выбрать те признаки, которые нам в данном случае важнее других.
Сторонники множественного наследования пытаются получить систему на все случаи жизни, что приводит к черезвычайному усложнению системы в целом и для каждого частного случая. По крайней мере мне не приходилось сталкиваться с задачами, которые реально требовали бы множественного наследования. А вот при отказе от наследования по реализации я прикинул количество copy/past для некоторых своих проектов и решил, что их будет угрожающе много.
№ 4750 16-05-2007 10:26 | |
Ответ на »сообщение 4749« (Владимир Лось)
___________________________
Дерево наследования строится на отношенниях "является частным случаем".
А если сущность имеет признаки, позволяющие ставить её в РАЗНЫЕ деревья "частных случаев" (IS-A)? Это к вопросу о конфликте между сторонниками и противниками одиночного/множественного наследования (хотя на самом деле конфликта НЕТ).
Сюда можно добавить сторонников и противников наследования как такового. :)
BTW, "кто такая" Композита?
№ 4749 16-05-2007 10:15 | |
Ответ на »сообщение 4747« (Сергей Перовский)
___________________________
Дерево наследования строится на отношенниях "является частным случаем".
А если сущность имеет признаки, позволяющие ставить её в РАЗНЫЕ деревья "частных случаев" (IS-A)? Это к вопросу о конфликте между сторонниками и противниками одиночного/множественного наследования (хотя на самом деле конфликта НЕТ).
А есть еще "входит в состав", там тоже деревья.
Ну так это - HAS-A - туту проблем никаких - "граничные условия" зачастую определяются прямо из механистической природы "отношений" составных частей целого...
А есть еще "посылает/принимает сигнал", тут возможна и сеть и шина.
Тут надо очень внимательно смотреть не "вылазит" ли отношение использования...
Почему внимательно, потому, что "использовать" - не просто "ссылаться", но ещё и зачастую "протокол" - собсна теперь формализовать с приходом Композиты это отношение будет неизмеримо легче!
Если одновременно графически изобразить связи наследования и вхождения, получится сеть, но на самом деле это наложение деревьев различной природы. Что считать надстройкой над чем, дело вкуса.
Это - "не дело вкуса" эти отношения - из "разных вселенных", с "разной поляризацией", "в разных плоскостях" (ортогональных) - не могут они быть "надстройкой" или "налогаться". Их просто "имеют в вдиду" и "учитывают"...
№ 4748 16-05-2007 07:55 | |
Ответ на »сообщение 4746« (Как слышно? Приём!)
___________________________
>>>Дерево - это один вход, много выходов.
Или наоборот :)
А может дерево и вообще не иметь отношения к идеологии входов/выходов.
№ 4747 16-05-2007 07:52 | |
Ответ на »сообщение 4745« (Как слышно? Приём!)
___________________________
>>>То есть наследование от ООП, а композиция - рукоделие в виде надстройки?
Это мне не понятно. Рассуждая о топологии взаимоотношений объектов нужно понимать какие взаимоотношения имеются в виду. Дерево наследования строится на отношенниях "является частным случаем". А есть еще "входит в состав", там тоже деревья. А есть еще "посылает/принимает сигнал", тут возможна и сеть и шина.
Какие связи будете рассматривать, такую топологию и получите. Если одновременно графически изобразить связи наследования и вхождения, получится сеть, но на самом деле это наложение деревьев различной природы. Что считать надстройкой над чем, дело вкуса.
Добавить свое сообщение
Отслеживать это обсуждение
Дополнительная навигация: |
|