Ответ на »сообщение 4764« (Владимир Лось)
___________________________
>>>Не происходило это, скорее всего, по трём возможным причинам:
>>>1.Вы очень аккуратно применяете парадигму MVC
Большинство объектов невидимы и к MVC отношения не имеют...
Скорее речь может идти о применении системного анализа.
Но в общем тут Вы правы, на критику ООП я обычно отвечаю цитатой из анекдота про кошек: "Вы их просто готовить не умеете".
>>>2.Вы никогда не сталкивались с языками, позволяющими проводить множественное наследования а-ля Си++.
Ну как можно не столкнуться с C++ :(
>>>3.Вы никогда не сталкивались с языками, позволяющими реализацию интерфейсов (как средства языка).
Ну тут уже ответили :)

Ответ на »сообщение 4764« (Владимир Лось)
___________________________
>>>3.Вы никогда не сталкивались с языками, позволяющими реализацию интерфейсов (как средства языка).
Вы забыли как сайт называется? ;-)

Ответ на »сообщение 4763« (Сергей Перовский)
___________________________
Не знаю, как у других, а у меня в программах ничего САМО ПО СЕБЕ не возникает :)
Других в этом постарайтесь не разуверивать...

Ну, например, писал я аналог VCL на TP5.5. Никаких потребностей в множественном наследовании не испытывал. Там действительно нужно очень аккуратное глубокое наследование с небольшой долей композиции. И свойство "цвет" вводится на очень ранних уровнях (ибо есть у всего, что видно на экране).
У вас там объекты поставлены в дерево, имеющее ветвление по специализации «отображаемый элемент управления». Ничего «лишнего» там в описаниях классов, как кроме функциональности, касаемой работы с такими контролами, больше и быть не могло.

А вот вводить в один список автомобили, мясорубки и плакаты на том основании, что у всех есть свойство "цвет" мне как то в голову не приходило.
Не происходило это, скорее всего, по трём возможным причинам:
1.Вы очень аккуратно применяете парадигму MVC (или что-то подобное из «более современных» шаблонов) даже на самом мелком уровне декомпозиции своих моделей.
2.Вы никогда не сталкивались с языками, позволяющими проводить множественное наследования а-ля Си++.
3.Вы никогда не сталкивались с языками, позволяющими реализацию интерфейсов (как средства языка).

Ответ на »сообщение 4762« (Владимир Лось)
___________________________
>>>Это шутка такая или - как?
>>>"Как в Делфи" поле "цвет", буде такой случимшись, возникает НЕ САМ ПО СЕБЕ
Не знаю, как у других, а у меня в программах ничего САМО ПО СЕБЕ не возникает :)
Так что не вижу повода для спора.
>>>Ну, например, коллекция объектов-контролов с полем BackgroundColor.
Ну, например, писал я аналог VCL на TP5.5. Никаких потребностей в множественном наследовании не испытывал. Там действительно нужно очень аккуратное глубокое наследование с небольшой долей композиции. И свойство "цвет" вводится на очень ранних уровнях (ибо есть у всего, что видно на экране).
А вот вводить в один список автомобили, мясорубки и плакаты на том основании, что у всех есть свойство "цвет" мне как то в голову не приходило.

Ответ на »сообщение 4761« (Сергей Перовский)
___________________________
(Долгое мучительное молчание в поисках подвоха или иронии...)
Что, действительно, надо объяснять?
Вам - по всему видать - да.

Если уж я решил, что у меня будет объект-свойство "цвет" (как в Дельфи), то никаких "цветных объектов" естественно не будет.
Это шутка такая или - как?
"Как в Делфи" поле "цвет", буде такой случимшись, возникает НЕ САМ ПО СЕБЕ, или по ЧЬЕМУ-ТО ПРОИЗВОЛУ, а - в соответствии с ТИПОМ ОБЪЕКТА, интерфейса, который поддерживает объект.
ПРОСТО, "самое по себе" поле появиться НЕ МОЖЕТ. Вы вводите его по причине того, что сделали заключение в процессе анализа, что ДАНЫЙ ТИП объекта ДОЛЖЕН в своём интерфейса (или в одном из интерфейсов) иметь такое поле.

И объекту-клиенту будет передаваться только "цвет".
Это потому, что КЛИЕНТ ОЖИДАЕТ, что ваш объект МОЖЕТ (или ДОЛЖЕН) предоставлять такое поле. Опять же - потому, что между этим клиентом и вашим объектом есть соглашение на счёт типа (класса), реализуемого вашим объектом.

Плохо представляю необходимость иметь коллекцию всех объектов, имеющих свойство "цвет".
Ну, например, коллекция объектов-контролов с полем BackgroundColor. Коллекция контролов, лежащих на форме (например) должна изменить свои фоны в зависимости от режима. Коллекция, как раз и ожидает, что сохранённые в ней объекты будут поддерживать интерфейс «объектов-контролов». Объект, перебирающий эту коллекцию не будет интересоваться какого именно типа будут сохранённые в коллекции объекты! Для объекта, изменяющего (назначающего) новый фоновый цвет у всех объектов-контролов в коллекции важен только один "аспект" (тип, класс) - тот, который "предъявляет" (содержит) поле BackgroundColor.

Ответ на »сообщение 4759« (Владимир Лось)
___________________________
>>>И как же вы (в рамках сегодняшних подходов к ОО-языкам) будете объяснять объекту-клиенты (или объекту-коллекции), знающему об "цветных объектах", что ваш автомоболь именно к ним и относится
(Долгое мучительное молчание в поисках подвоха или иронии...)
Что, действительно, надо объяснять?
Если уж я решил, что у меня будет объект-свойство "цвет" (как в Дельфи), то никаких "цветных объектов" естественно не будет. И объекту-клиенту будет передаваться только "цвет". Плохо представляю необходимость иметь коллекцию всех объектов, имеющих свойство "цвет".
У Эффеля есть карикатура с подписью: "для простоты я расставила все предметы в вашем кабинете по алфавиту" :)

В дополнение к »сообщение 4759« (Владимир Лось)
___________________________
Вам понятна мысль?
То, что вы объявиле какое-то там поле - ничего для окружающего мира абсолютно не значит, если у вас это поле не объявлено в рамках поддержки некоего интерфейса, которое от вас ждут окружающие! А для этого вам нужно сделать некое синтаксическое конструкцио в объявлении вашего класса в соответствии с особенностями используемого вами языка.
А "просто привести тип" в месте использования - в подавляющем большинстве случаев - прямая дорога к АВОСТУ. В прочем, в рамках разрабатываемой системы и современных ЯП это просто не будет иметь смысла.

Ответ на »сообщение 4758« (Сергей Перовский)
___________________________
Чем наследовать автомобиль одновременно от прототипов "движущийся объект" и "цветной объект", не проще ли добавить объектное свойство "цвет"? И всегда будет ясно "чего имелось в виду".
Да что вы говорите? И как же вы (в рамках сегодняшних подходов к ОО-языкам) будете объяснять объекту-клиенты (или объекту-коллекции), знающему об "цветных объектах", что ваш автомоболь именно к ним и относится (при том, что "наследование" у вас прошло по линии атрибутики "движущихся объектов")?

Ответ на »сообщение 4754« (Владимир Лось)
___________________________
>>>Другое дело, что давая некоторые преимущества, множественное наследование (в инкарнации Си++) не избавляет от кучи недоразумений и "ступора выбора чего имелось в виду". :о)
Если заглянуть внутрь реализации множественного наследования, то увидим там как раз обсуждаемое сочетание наследования и композиции. Только в упаковке, которая затрудняет управление и может приводить к неоднозначностям. Чем наследовать автомобиль одновременно от прототипов "движущийся объект" и "цветной объект", не проще ли добавить объектное свойство "цвет"? И всегда будет ясно "чего имелось в виду".

Ответ на »сообщение 4755« (info21)
___________________________
А дерево вырастает как раз из борьбы за сохранение контроля в условиях нарастающей энтропии при работе с шиной -- из конкретного разглядывания ветвей всяких WITH внутри разных HandleMsg, выделения общих процедур, вызывающихся (ну в точности "двойная диспетчеризация") из этих ветвей и сначала скрытых в модуле, потом выводимых "наружу" и закрепляемых в базовых ABSTRACT-интерфейсах... так примерно.
Это вы сейчас в точности описали примерную методику построения прототипов приложений в Смолток-системах... :о)