дополнение к »сообщение 2985« (ы)
___________________________
Системы-то по определению, не столько элементы, сколько СВЯЗИ.
... А наипервейшей и наиглавнейшей связью для нас является функциональная зависимость... Патамушто там математики больше порылись. :о)

Ответ на »сообщение 2982« (Сергей Перовский)
___________________________
Если система сильносвязная...
И как это отображается на природЫ модельных связей в программах? На их способность к модификации при изменении в модели? Системы-то по определению, не столько элементы, сколько СВЯЗИ.

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

>>>Мне кажется, если бы все пользовались этим правилом, 90% софта вообще не было бы написано.

И слава богу.

Попробуйте обойтись без 90% программ, которыми пользуетесь. Я именно их имел в виду, а не бесчисленные клоны какого-нибудь винампа. Да взять хотя бы тот же Excel - исключительно полезная вещь во многих отношениях. А ведь широко известно, что изначально электронная таблица позиционировалась как инструмент для решения весьма специфических задач финансового анализа. Если бы создатели Excel были последовательны в развитии своего продукта, у нас был бы сейчас офигительный пакет для финансового анализа. Но с его помощью было бы невозможно набрать и распечатать произвольную таблицу.

Вот только программисты не хотят становится специалистами в конкретных узких областях.

Область, в которой я работаю (промысловая геофизика), нельзя назвать узкой. Чтобы её освоить, мне надо ещё как минимум 3 высших образования получить (геофизическое, геологическое, техническое нефтегазового профиля). А потом ещё постоянно поддерживать свои знания в актуальном состоянии. Это же наука, она постоянно развивается. Даже специалисты в конкретных узких областях зачастую не могут предсказать, как изменятся в будущем геофизические методики и аппаратура.

А ведь в программе есть ещё кое-что кроме собственно предметной области. Например, пользовательский интерфейс. С точки зрения математики 2x2=4 было, есть и будет всегда. А человек может захотеть представить это равенство массой способов, разными шрифтами, цветами, римскими цифрами, прописью, на графике, диаграмме, таблично, чтобы мышой можно было интерактивно значения менять и т.п. Что уж говорить о том, когда математическая модель "чуть сложнее", чем 2x2=4? Что я должен изучить, чтобы научиться безошибочно определять, кому какой способ визуализации понадобится хотя бы сегодня, не говоря уже про текущую пятилетку?

Поэтому либо пишут нечто общеупотребительное, в чем каждый понимает, либо красивые бессмысленные прикладные программы.

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

Вот, к примеру, фирма, разрабатывающая программу для расчета строительных конструкций. Там работают только специалисты по расчету строительных конструкций, освоившие программирование. Ни одного "просто программиста". И это правильно.

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

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

Ответ на »сообщение 2979« (info21)
___________________________
Если система сильносвязная, то ...

Все-таки в большой системе обычно бывают квази-автономные куски.

Кроме того, что значит, сильносвязная?
Система-то, может, и сильносвязная, но модули, реализующие ее абстракции... и т.д.
Тут мы, конечно, возвращаемся к проблеме понимания задачи -- насколько оно структурировано........

Ответ на »сообщение 2979« (info21)
___________________________
>>>Но все-таки совершенно замкнутые модули --черные ящики-- обладают большой устойчивостью и независимотью.
Если задача легко делится на подзадачи, то безусловно.
Если система сильносвязная, то изоляция отдельных подсистем будет обходится слишком дорого.
Опят таки нужно смотреть по месту.

Ответ на »сообщение 2980« (Как слышно? Приём!)
___________________________
>>>Беда в том, что ООП суют в дело и не в дело, а не в том, что он плох.
+1
Беда в том, что в программирование пришла масса народу с очень низкой культурой мышления. И выучив что нибудь (язык, метод, подход) суют это к месту и не к месту.
Я помню паническую статью одного американского вебдизайнера, еще времен текстовых редакторов и HTML: скоро появяться визуальные редакторы вебстраниц и наши знание HTML станут невостребованными - куда мы, бедные, денемся; а мы так много потратили сил и средств на его изучение.
>>>>ООП в мэйнстриме
Поэтому с его помощью делается больше глупостей, чем другими методами.

>>> чем тут объектное программирование хуже модульного

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

А так всё отлично. И главное - ООП в мэйнстриме, fashionable method и всё такое.
Беда в том, что ООП суют в дело и не в дело, а не в том, что он плох.

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

Ответ на »сообщение 2976« (info21)
___________________________
>>>Можно сказать, сам взгляд на прикладную область меняется. Иногда радикально.
Тогда, что удивляться, что систему придется спроектировать и разработать заново? Конечно, некоторый реинжениринг возможен и я не вижу, чем тут объектное программирование хуже модульного.


А кто тут удивляется? :))
Бывает, и не раз взгляд меняется.

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

Ответ на »сообщение 2976« (info21)
___________________________
>>>Можно сказать, сам взгляд на прикладную область меняется. Иногда радикально.
Тогда, что удивляться, что систему придется спроектировать и разработать заново? Конечно, некоторый реинжениринг возможен и я не вижу, чем тут объектное программирование хуже модульного.

Ответ на »сообщение 2975« (Денис Зайцев)
___________________________
>>>Мне кажется, если бы все пользовались этим правилом, 90% софта вообще не было бы написано.
И слава богу. Вот только программисты не хотят становится специалистами в конкретных узких областях. Поэтому либо пишут нечто общеупотребительное, в чем каждый понимает, либо красивые бессмысленные прикладные программы.
Вот, к примеру, фирма, разрабатывающая программу для расчета строительных конструкций. Там работают только специалисты по расчету строительных конструкций, освоившие программирование. Ни одного "просто программиста". И это правильно.
Беда, коль сапоги начнет точать пирожник(С)