Модифицированная задача Кая или пара слов об ООП

[bowhill]

Есть один тезис, который у сторонников ООП не получается опровергнуть, поэтому его стараются просто игнорировать — граф нельзя представить иерархией.

Статические иерархические модели можно отлично реализовывать средствами ООП, но в жизни их не так много, всё больше графы. Да ещё и динамические.

Это как поиск философского камня или вечного двигателя. Люди 25 лет вертят буквы S, I, T и H, уже мозоли натёрли, а счастья нет. Но вот-вот будет.

Comments

[bowhill.livejournal.com]

Что можно делать с графами. С этими и далее, если есть интерес работать с кодом как с графом.

Но вообще, в дообъектных языках связи не были иерархическими, и что делали? Программы писали.

[gineer.livejournal.com]

Мой поинт был в -- что ТЕХНИЧЕСКИ можно делать с графами,
а не как их можно использовать.

А графы, я упомянул как самый просто и наглядный формальный способ представления связей.

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

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

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

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

[bowhill.livejournal.com]

Да почему же это человек не способен? Схему с логичными связями он понимать неспособен, а большую, с химерами и костылями, способен. И не надо всё в голове держать: есть код, документация, анализаторы кода. Автоматизировать разработку вообще проще, чем создавать новую парадигму, которая к тому же постоянно рестартует с нуля. Такую бы энергию, да в мирных целях.

Процесс разработки — предмет непростой, но не надо думать, что все его сложности можно решить волшебным синтаксисом. Который заменит и процесс, и голову, и документацию, и средства, и всё прочее. Сам будет всё делать. На этот миф люди и ловятся.

И большие системы с тысячами сущностей пишутся отнюдь не только на инкапсуляции или наследовании. И если структура (условный csv) используется во множестве мест, то куда её инкапсулировать и зачем? К слову, структурирование и модульность никто не отменял.

[gineer.livejournal.com]

\\Схему с логичными связями он понимать неспособен, а большую, с химерами и костылями, способен.

Весь вопрос в том -- какого объема.

[bowhill.livejournal.com]

А здесь ответ универсальнее программирования — не больше такого объёма, какой человек может понять. Если за процессом не стоит разумная деятельность, то сам по себе процесс хорошо работать не будет, и разработка не исключение.