>>> Это начало любого серьезного исследования.
>>> Хотя, конечно, отнюдь не конец.

Да как раз именно конец. В смысле полный конец. Бетонирование.
Далее продолжать по Сергею Перовскому и нельзя - надо строить новую
иерархию, если это не калькулятор, а уже игровая приставка.
Заново транзисторы изобретать, микросхемы, аккумуляторы,
схемы работы шин, проверки сбоев, ЖК экраны и многое другое.

Можно и алхимию к началам химии относить.

>>> Выходит, беремся за модуль 1 - получился один предок.
>>> Взяли за модуль N - обратно предок. Куда ни плюнь, везде предки!

Ну да! Рюриковичи мы. А могли бы быть и Тахтамышата или потомки Лжедмитрия,
если бы он себя хорошенько пропиарил.

Какой-то смысл в отыскании "главного" предка как бы есть - это тот,
взявшись за который получим иерархию с минимальным числом уровней.
Однако такая оптимальная иерархия отличается от наихудшей в два раза.
Если сравним близкую к оптимальной от случайной и, более того,
оптимизированной по наитию, то разница будет процентов в сорок - двадцать.
И в этом смысле отыскание самого правильного предка вопрос раздувания щёк.

Ответ на »сообщение 5920« (Как слышно? Приём!)
___________________________


...
Берёмся за любой модуль и вытаскиваем всю систему в более-менее одну линию.
Обратите внимание - любой!
Специалисты не нужны :)
Получили милую сердцу иерархию.
модуль в руках - главный предок и далее по связям потомки.
...


Выходит, беремся за модуль 1 - получился один предок. Взяли за модуль N - обратно предок. Куда ни плюнь, везде предки! Какая хитрозакрученная ООП-изация, однако!

Ответ на »сообщение 5920« (Как слышно? Приём!)
___________________________

...Иерархия - приём доисследовательский, приём классификации.

Ну, это Вы загнули... :-)
Это начало любого серьезного исследования.
Хотя, конечно, отнюдь не конец.

Ответ на »сообщение 5921« (Как слышно? Приём!)
___________________________

А что если в поставку школьного ББ встроить игрушки?

Там есть две: Блэкбокс (с которого я начилал лицейский курс -- они у меня играли пару занятий, привыкая к среде; с удивлением обнаружил, что 8-классники не могли прочесть и понять правила игры...)

Вторая -- Тетрис незабвенного ketmar'а (куда-то исчез). Правда, немножко недоделанный. Кто бы доделал...

Если есть еще игрушки -- конечно, надо включать.

Ответ на »сообщение 5919« (Сергей Перовский)
___________________________

Вы имеете в виду крайности, но есть же и промежуточный вариант, о котором я и пытаюсь толковать: когда новые требования (не обязательно из числа совсем уж основных) повлияют именно на иерархию, а не на костяк структуры программы.

Точнее, если опереть структуру только на иерархию, то эти новые требования будут "основными". А если роль иерархии ослабить, то и новые требования перестают быть основными, а переходят в разряд уточняющих. Вот такая диалектика.

Разумеется, классификации (а с ними иерархии) никуда не деваются, просто мы понимаем больше, чтобы не зацикливаться только на них.

Но проблема тщательного выстраивания все равно остается, просто она переходит в другую плоскость, становится менее критичной.

Но тут хорошо примеры обсуждать, чтобы понять, одно ли и то же мы тут все имеем в виду. Обещаюсь известить, когда буду готов предъявить небольшой реальный пример.

Ответ на »сообщение 5919« (Сергей Перовский)
___________________________
>>> Ни один аналитик не определит структуру программы,
>>> которая со временем превратится из калькулятора в игрушку-стрелялку.

Интересная мысль. Речь даже не о карманных игровых пультах.
Вспомнил о Word, в котором был встроен первый этап Doom.

А что если в поставку школьного ББ встроить игрушки?

>>> Но тут вопрос эмфазы.
Нет, дело не в акцентах.
Дело в наследовании устаревших методик.
В мифологичности мышления.
Иерархия - приём доисследовательский, приём классификации.
(Что очень характерно для сторонника наследования СП.)
Как именно она выстраивается всё равно и я постараюсь это показать далее.
Господин Fktrc её тащит далее - в агрегацию, где она вообще ни с какого боку.

>>> трудности выстраивания иерархии типов могут резко уменьшится
>>> при надлежащем использовании Оберон-шины
Это полумера вроде фигового листка полиморфизма.

>>> нужно смотреть ... подходяющую небольшую подсистемку

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

Откуда такая удивительная система может получится?
От фанатичного следования принципу простоты только.

Нормальная сложная система всё же имеет другую топологию.
Связей больше, чем N-1.
И тут фокус с вытягиванием в иерархию не пройдёт.
Появившиеся кольца мешают.
Ясное дело, срочно используем полиморфизм или другие горизонтальные,
или, в общем случае, диагональные связи.
Но дерево иерархий не замай! :)
Хорошо, когда колец мало.
Эти припарки и подвязывания скотчем ещё работают.
А если много?
Кирдык со всех сторон!

Поэтому для каждого чиха - своя система со своим деревом.
Вот для "подходящих небольших подсистемок" ООП с наследованием работает.
Но, вроде бы, любая методика работает в этом случае.
Хочь из хлеба слепи, хочь кувалдой пройдись, хочь напильником подрихтуй.

Речь о сложных системах, о долгоживущих и меняющихся.
О системах, которые выносят ремонт на ходу.

Ответ на »сообщение 5918« (info21)
___________________________
Но тут вопрос эмфазы.
Это когда где болит? :)

Рассуждения СП, похоже, подразумевают возможность фиксации требований на систему (пусть и после изрядной работы аналитика-специалиста).
Скажем, "основных требований". Аналитик на то и аналитик, чтобы уметь выделять из частностей общее, то, что меняться не будет. А если изменится, то придется создавать структуру заново.
Ни один аналитик не определит структуру программы, которая со временем превратится из калькулятора в игрушку-стрелялку.
Если для задач, с которыми Вы работаете, невозможно фиксировать даже основные требования, то ООП противопоказано. Для Вас.
Это не значит, что ООП устарело. Это Вы вышли за границы его применимости. Нормально. По этому я и не сторонник чисто объектных языков.

Ответ на »сообщение 5917« (Сергей Перовский)
___________________________

Ответ на »сообщение 5916« (Fktrc)
___________________________
Более естественной и гибкой парадигмой является агрегация.
Давайте перестанем противопоставлять наследование и агрегацию. Это прекрасно сочетающиеся инструменты. ...

Правильно. Но тут вопрос эмфазы.
Через рассуждения С.Перовского красной нитью проходят некие идеи, которые сильно резонируют с тем, с чем я вожусь. Чтобы детально сравнить, насколько согласуется то, что вдое нас имеют в виду, нужно смотреть код (может быть, подходяющую небольшую подсистемку я даже выложу на zinnamturm.eu, но СП ББ не юзает...).

Так вот, суммирую свой опыт в столь же общем формате, как это делал СП:
трудности выстраивания иерархии типов могут резко уменьшится при надлежащем использовании Оберон-шины вместе с композицией (агрегацией). Резко -- из разряда почти препятствия для реализации до степени просто некоторого засорения "словаря" (для прочистки и минимизации коего нужна не столько квалификация разработчика, сколько опыт реального использования системы и вдумчивое рассматривание опыта; специалист-предметник тут даже не поможет, т.к. трудность в труднопредсказуемых комбинациях мелких деталей).

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

Кстати, все это перекликается с понятием agile development и некими картниками из моих лекций (объяснение того, что это такое).

Ответ на »сообщение 5916« (Fktrc)
___________________________
Более естественной и гибкой парадигмой является агрегация.
Давайте перестанем противопоставлять наследование и агрегацию. Это прекрасно сочетающиеся инструменты.
Приводя примеры неудачного использования наследования, не будем забывать, что речь идет о программировании сложных систем и основные проблемы в головах, а не в инструментах.
Почему две трети проектов ERP систем не доходят до запуска? Потому, что нет адекватной математической модели, а не потому, что используется ООП.
.NET FrameWork построен далеко не лучшим образом, но чему тут удивляться?
Построение иерархий должны выполнять несколько очень квалифицированных человек, а не армия программистов. Попытка построить иерархии объектов на все случаи жизни вообще имеет мало шансов на успех.