Ответ на »сообщение 4266« (hugi)
___________________________


Мне кажется, что можно уточнить постановку вопроса. Дело не в наследовании как таковом, а в его "глубине" и назначении.
Идеальный вариант -- 2 уровня:
(1) абстрактный (интерфейсный) класс;
(2) класс реализация.
Все что сверх этого, таит в себе дополнительные проблемы.
В языках же с явной поддержкой интерфейсов, о которых говорил hugi, даже этого не надо.
Если довести эту мысль до предела (и может быть  -- до абсурда :)), то наследование вообще может стать излишним.
На самом деле предложенная Вами схема не всегда адекватна. Например, когда необходимо банальное расширение функциональности. Пример такой: пользователи Web-сайта -- Гость, Пользователь, Администратор. Функциональность последовательно расширяется от Гостя до Администратора, т.е. имеем уже три уровня в иерархии наследования.

Последняя фраза вызывает у меня сомнение.


Функциональность последовательно расширяется от Гостя до Администратора, т.е. имеем уже три уровня в иерархии наследования.

Считаете ли Вы Администратора разновидностью Гостя?
Мне так не кажется, поэтому Ваше "т.е." кажется мне "натяжкой".

Ответ на »сообщение 4262« (hugi)
___________________________
Да поймите же, есть очень сложные сущности, для которых выделить элементарную функциональность (набор базовых операций) очень трудно (если не невозможно)
Сложные... говорите... Я приводил ссылку на разработанную нами систему. Вы относите ее к простым? ERP+MES+CRM+SCM+... Хм...

Поэтому классификация и наследование -- очень хорошие способы разбиения функциональности и, следовательно, борьбы со сложностью окружающего мира. Ваш подход в большинстве случаев преумножает сложность, а не избавляет от неё
Вы уверены, что знаете «мой подход» настолько хорошо, чтобы делать выводы? Удивительно... Тот факт, что трудоемкость разработки была снижена на два порядка... свидетельствует о том, что мой подход «преумножает сложность»?..

Так Буч говорит именно о множестве возможных классификаций. О наследовании умалчивает. Так что зря Вы так с ним...
Не хотелось бы мне цитировать Г. Буча, но если будете настаивать...

И ещё: говорить "наследование -- классификация" неверно, ибо это разные вещи. Можно сказать: "наследование основано на классификации", но это разные вещи... совершенно разные...
Вы очень невнимательно читали то, что было мной написано...

Ответ на »сообщение 4256« (sdf)
___________________________
a) смысл (семантика) не может быть общим (для группы людей) ==> смысл субъективен (не отчуждаем от человека)
Ваше стройное (я бы даже сказал... красивое) логическое построение... не верно. Смысл действительно не может быть общим, каждый должен его постичь самостоятельно. Но из этого не следует субъективность смысла. Странно, правда? (Да, простят меня те, кто это уже читал...) Будда говорил своим ученикам, указывая на Луну: «Не смотрите на палец, смотрите на Луну, если вы будите смотреть на палец, Луну вы не увидите». Смысл (Луна) существует объективно, но каждый должен открыть (увидеть) его сам, и каждого будет сложится представление. Определения, словесные описания (палец) важны не сами по себе... надо не в них вчитываться, а попытаться понять то, на что они указывают.

Смысл действительно нельзя «извлечь» из человека (в отличие от знаний), но можно понять то, открыт ли смысл данному человеку или нет
каким образом можно понять, открыт или нет? что есть критерии понимания? открыт ли, например, мне смысл "склада"? кто это может выявить? является ли этот процесс выявления объективным или он все же субъективен?
Нет критериев, которые можно было бы описать... В народе говорят: «Рыбак рыбака...», вот и вся премудрость...

Ответ на »сообщение 4247« (AVC)
Единственное, что меня немного смущает в данной цепочке, -- то, что абстрактные классы Stores.Store и Models.Model, оставаясь абстрактными, добавляют к записи скрытые поля. Все-таки элемент реализации...

Если Вас это немного смущает, то меня это сильно возмущает. Столько слов о компонентности и вдруг бац - оказывается фреймворк Блэкбокса не компонентен! Из-за скрытых полей у абстрактных типов нельзя заменить один модуль на другой аналогичный от другого производителя если другой производитель не знает о всех скрытых полях (но знать их можно только если доступен исходный текст). Самое страшное, что это неисправимая ошибка - всё надо переписывать полностью :-(

Ответ на »сообщение 4204« (ASU)

Наследование (в ООП) – всегда классификация ...

Конкретно в Блэкбоксе: дан базовый тип View. От него производятся разные, никак между собой не связанные конкретные вьюшки.
Никакого отношения к классификации это не имеет, если не считать классификацией любое определение -- что малоинтересно, ибо в таком вырожденном случае понятие классификации лишнее.

(ЗЫ Какое однако любопытное упорное увязывание наследования и классификации... надо полагать, свидетельство силы импринтинга в юном возрасте.)

Ответ на »сообщение 4222« (AVC)
___________________________

Мне кажется, что можно уточнить постановку вопроса. Дело не в наследовании как таковом, а в его "глубине" и назначении.
Идеальный вариант -- 2 уровня:
(1) абстрактный (интерфейсный) класс;
(2) класс реализация.
Все что сверх этого, таит в себе дополнительные проблемы.
В языках же с явной поддержкой интерфейсов, о которых говорил hugi, даже этого не надо.
Если довести эту мысль до предела (и может быть  -- до абсурда :)), то наследование вообще может стать излишним.
На самом деле предложенная Вами схема не всегда адекватна. Например, когда необходимо банальное расширение функциональности. Пример такой: пользователи Web-сайта -- Гость, Пользователь, Администратор. Функциональность последовательно расширяется от Гостя до Администратора, т.е. имеем уже три уровня в иерархии наследования.
В языках же с явной поддержкой интерфейсов их иерархия наследования органично сочетается с иерархией наследования реализующих их классов, так что, я думаю, наследование не перестанет быть нужным в ближайшее время. Хотя агрегация потенциально предоставляет более широкие возможности, но и сложностей больше.

Ответ на »сообщение 4264« (hugi)
___________________________

Касательно пункта 1: есть куча моделей plugin'ов, которые очень даже неплохо реализуются с использованием имеющихся на сегодняшний день механизмов. Дальнейшие разъяснения здесь, я думаю, следует опустить.
Касательно пунктов 2, 3, 4: см. пункт 1.

На мой взгляд, поднятая Вами проблема до определённой степени надумана, либо Вы не представили достаточной аргументации.

Согласен с Вами: моделей много, и они неплохо работают. Тут я даже когда-то писал, что из них мне симпатичнее всего Eclipse http://eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html .

Речь немного о другом: сводятся ли упоминаемые Вами механизмы, грубо говоря, к реализации триады "инкапсуляция-наследование-полиморфизм"? Мне видится, что существует еще что-то, не менее значимое, но не получившее до сих пор ни общепринятого названия, ни статуса необходимого компонента программистского инструментария.

Ответ на »сообщение 4216« (Горбунов-Посадов)
___________________________

Касательно пункта 1: есть куча моделей plugin'ов, которые очень даже неплохо реализуются с использованием имеющихся на сегодняшний день механизмов. Дальнейшие разъяснения здесь, я думаю, следует опустить.
Касательно пунктов 2, 3, 4: см. пункт 1.

На мой взгляд, поднятая Вами проблема до определённой степени надумана, либо Вы не представили достаточной аргументации.

Ответ на »сообщение 4261« (hugi)
___________________________

"Да, эта фраза включается теперь даже в некоторые антологии как цитата из Сталина...", -- так что не думаю, что моя ошибка так уж непростительна.

Ответ на »сообщение 4209« (Владимир Лось)
___________________________

Если вы имете в виду слова "нет человека - нет проблемы", то никогда подобной чуши (на счёт того, что эти слова говорил Сталин), не повторяйте. А также не делайте аллюзий по сему поводу.
Сталин никогда и нигде этих слов не говорил. Эти слова вложил в уста Сталина писатель Рыбаков в "Детях Арбата"... ( см.например здесь: http://magazines.russ.ru/druzhba/2000/1/volkov.html)

а почему вы так категорично утверждаете, что "Сталин никогда и нигде этих слов не говорил"? исходя из той информации, которой обладаю, сталин скорее это не говорил, чем говорил.

но в точности знать, что и где говорил сталин хотя бы в течении одного отдельно взятого месяца своей жизни, вряд ли кто мог тогда, а тем более сейчас.

Ответ на »сообщение 4204« (ASU)
___________________________

Хм... сколько степеней свободы имеет палец? А рука? А все тело человека? Продолжать или уже понятно?.. Сколько музыкальных произведений существует? Много?! А нот всего семь... а параметра только три... Сколько действий может совершить человек? Много?! А если разложить на простые движения (которых всего-то два: поступательное и вращательное)... «Зачем делать сложным то, что проще простого?». Характеристики (свойства) – это проявления (вовне) композиций из очень малого количества исходных (внутренних) элементов. Можно перечислять композиции, а можно попробовать понять их основу и правила построения (создания).
Да поймите же, есть очень сложные сущности, для которых выделить элементарную функциональность (набор базовых операций) очень трудно (если не невозможно). Как пример -- тот самый HomoSapiens. Поэтому классификация и наследование -- очень хорошие способы разбиения функциональности и, следовательно, борьбы со сложностью окружающего мира. Ваш подход в большинстве случаев преумножает сложность, а не избавляет от неё.

Попробую еще раз... Наследование (в ООП) – всегда классификация, но не всякая классификация – наследование... «Любая селедка – рыба, но не всякая рыба – селедка». Буч приводит надуманный пример (рисунок) с разными вагончиками и говорит, что поскольку способов классификации может быть много, то и иерархий наследования тоже может быть много. Непонятно?..
Так Буч говорит именно о множестве возможных классификаций. О наследовании умалчивает. Так что зря Вы так с ним... И ещё: говорить "наследование -- классификация" неверно, ибо это разные вещи. Можно сказать: "наследование основано на классификации", но это разные вещи... совершенно разные...

Вы хотели походить на Г. Буча, я этому не противился... и это для Вас оскорбительно? Может быть тогда не надо на него походить, может быть лучше оставаться самим собой?..
Но я прошу у Вас прощения, раз мое замечание Вас столь сильно задело. Обидеть Вас я не хотел.
Ах... Вы, видимо, не в курсе предыстории... Простите.