Лыцарь пичальнава образа - Об информационном обществе 6 [entries|archive|friends|userinfo]
silly_sad

[ userinfo | ljr userinfo ]
[ archive | journal archive ]

Об информационном обществе 6 [Mar. 5th, 2007|05:20 pm]
Previous Entry Add to Memories Tell A Friend Next Entry
Люди за 100000 лет худо-бедно научились классифицировать типы наблюдаемых объектов,
но до сих пор абсолютно неумеют классифицировать типы отношений между объектами,
хотя казалось бы тип умственной деятельности тот же... да вот клин какой-то вбит
и не даёт рассудить человеку ничего путного о таком простом объекте как тип оношений.

Все руководства, мануалы, статьи и хауты дружно лажают, когда речь заходит о межпрограмных
взаимодействиях (нет-нет я не буду ничего умничать про семафоры и параллельные вычисления!)
Простейшие вещи: настроить пару-тройку программ, чтобы они знали друг о друге то,
что им нужно знать - любой кулхацкер расскажет вам чо надо прописать и в какие в конфиги,
но на вопрос: "откуда программа узнает в какой конфиг она должна посмотреть?" в лучшем
случае смолчит, сэкономив время слушателей, на пространной болтовне об Архитектуре(tm).

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

И снова вспоминаю что мы живём в Информационном Обществе(tm), члены которого в большинстве
затрудняются рассудить о простейших движениях информации в элементарных информационных системах,
а основополагающий вопрос IT: "кто кому какую инфу сообщает?" ставит их в тупик.
Не заточен современный Объектно Ориентированный мозг для понимания процессов обработки инфы.
LinkLeave a comment

Comments:
[User Picture]
From:[info]vitus_wagner@lj
Date:March 5th, 2007 - 11:48 am
(Link)
--- Долгая история. Все дело в том, что местные программисты пошли
по неверному пути. Этот путь называется объектно ориентированный подход
в программировании. На самом деле это мина с часовым механизмом в
красивой упаковке. В очень красивой упаковке.
© П. Шумил. «Иди, поймай свою звезду»
[User Picture]
From:[info]os80@lj
Date:March 5th, 2007 - 12:46 pm
(Link)
Витус, а конструктив какой? Каким путём надо идти, если не ООП?
[User Picture]
From:[info]vitus_wagner@lj
Date:March 6th, 2007 - 04:29 am
(Link)
Головой думать. Не существует "единственно верного пути" (тм). С этим - к Зюганову.

Общий принцип такой - если существует математическая модель, описывающая данную проблемную область, то подход, базирующийся на этой модели - заведомо эффективнее, чем объектный. Пример - реляционные БД с их ER-моделированием или растровые GIS.

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

Но ключевым здесь является видение всей системы в целом и аккуратная декомпозиция её на объекты и отношения. OOD в первую очередь. А уж понадобится ли OOP - это после декомпозиции смотреть надо. Может быть система декомпозируется на что-то такое простое, что можно будет в императивном или функциональном стиле это реализовать.

В общем, применять UML на стадии проектирования - куда полезнее чем C++ или Java на стадии реализации.
Но и UML - не панацея.
From:[info]silly_sad@lj
Date:March 6th, 2007 - 04:59 am
(Link)
мне uml именно как язык не понравился очень сильно, он не проясняет а скорее путает, он изначально заточен под ООП причём аж сквозит, он навязывает некий подход вместо того чтобы отражать ситуацию, а все остальные приятные фишки они как бы сбоку, поэтому гораздо удобнее пользоваться старыми проверенными способами записи:
ER-диаграммами
Диаграммами состояний КА
Диаграммами потоков данных (подобными тем которые применяются в телефонии - очень удобные)
[User Picture]
From:[info]vitus_wagner@lj
Date:March 6th, 2007 - 05:39 am
(Link)
ER диаграммы и диаграммы состояний КА - это примеры ситуаций, когда у нас ЕСТЬ специальная математика под нашу задачу - реляционная алгебра или теория конечных автоматов. В этих случаях, несомненно, надо использовать её.

А более общаяя (поэтому более сложная и менее поддающаяся оптимизации) объектная модель должна применяться в тех случаях, когда более частные модели не подходят. И то, если при декомпозиции удается свести систему к группе подсистем, каждая из которых описывается более частной теорией, после этого разбиения на подсистемы про ОО следует забыть.
[User Picture]
From:[info]os80@lj
Date:March 6th, 2007 - 09:24 am
(Link)
Совершенно с Вами согласен. Однако есть ещё такая статья (http://russian.joelonsoftware.com/Articles/FiveWorlds.html), Вы её, наверное, читали, но всё равно. Есть такие типы ПО ("одноразовые программы"), которые исполняют 4-5 раз, потом думают, что "а если другой критерий применить?" (критерии эти мы должны сами из головы выдумывать). Ну и т. д. Так вот там именно ООП даёт такую гибкость, которой сложно достичь с помощью неООП.
ООП и ФП считаю (как неспец) ортогональными понятиями, друг другу не мешающими.
[User Picture]
From:[info]mehos@lj
Date:March 5th, 2007 - 06:39 pm
(Link)
прочетал два раза. не смешно.