проблемы объектного сознания

[fisher]

проблемы объектного сознания

выношу в отдельный тред, все запасаемся бисером и попкорном!
значит, тема очень флеймовая, поэтому убить её можно будет элементарно (не сомневаюсь, что эт опроизойдет - у меня лишь робкая надежда, что это произойдет не мгновенно).

итак, хочется собрать воедино - хотя бы ссылками на имеющиеся "фундаментальные" тексты - все вопросы касательно oop vs не-oop.
c чего всё начиналось:
http://phpclub.ru/talk/showthread.php?s=&threadid=81731

Автор оригинала: fixxxer
ммм. проблема то не в объектной идеологии, а в том, что объектный подход очень чувствителен к косякам и все надо делать очень аккуратно, иначе получается дикая помойка. требуется намного больше думать головным мозгом, и тщательно подходить к архитектурным решениям =) зато куча профита и экономии времени на разработку при грамотно заложенном фундаменте. если сразу заложены косяки, то это выходит бомба замедленного действия и мысль "а ну его нах.. этот ооп" вполне предсказуема

но это действительно где нибудь в другом месте надо обсудить

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

программа = данные + работа с данными (тезис классиков "данные+алгоритмы" в эпоху 1С бугалтерии и сосальных сетей выглядит неубедительно). объекты - промежуточные построения, умозрительные. то есть, вторичны - данные и работа над ними не обязательно "объекты". программа либо полезна либо бесполезна. то есть суть работы - результат, не процесс (ну закипайте же скорее, учоные!). объектная парадигма как сладкая пища для ума - моделирование не в области жизни а в области монад - подмена: программирование ради программирования. многочисленные споры, паттерны, только запутывающие новичка. паттерны - как метод наведения порядка: ребят, вот делайте так и меньше запутаетесь. красивый язык и множество умозрительных конструкций как средство построения мирка, и новой иерархии (не могу создать бизнес или достичь результата - так буду хотя бы выглядеть мега-умным). один мой коллега - хороший парень - на полном серьезе как-то предлагал любой объект рожать через фабрики, потому что там проще подменить процесс рождения, если вместо "тяжелого объекта" надо по вопросам производительности поставить "легкий" (не говорю что абсолютно плохая идея - просто иллюстрация образа мышления). много мелких объектов - много операций над CPU, тормоза, высокая стоимость владения (стоимость владения большого веб-проекта в разы превышает фонд зп).

наконец, ниже пояса. инкапсуляция как одобрение интеллектуальной слепоты (мне неважно что там - унаследую и понеслась. пример - одна из моих функций "следить за производительностью". регулярно нахожу в коде циклическое создание какого-то Model объекта, который лезет во внешний сервис за данными, хотя эти данные в этом конкретном месте не нужны. то есть - слепота, не позволяющая опуститься на "физический уровень" и думать не в пространстве монад а в пространстве утилизации конкретных имеющихся ресурсов. в приведенном примере - очевидный ошибка общей архитектуры, с точки зрения апи, то есть не вина конкретного человека кто использует model, но мы берем тупо model потому что он делает то, что нам нужно и всё остальное пофиг). интеллектуальная слепота как метод заработка - роботы-кодеры, продажа отчуждаемых библиотек. ну и в крышку гроба - тотальная не-математичность, не-реляционность и сплошной ОРМ.

пока хватит

P.S. сам я пишу "умеренный объектный код" и ни в коем случае не пропагандирую отказ от. просто вскрываю основные на мой взгляд проблемы.

 

[Scud]

Ну если ссылками и на фундаментальные то вот например:

Cuno Pfister "Component Software"

В статье описывается не ОО-подход, а КО-подход (Компонентно-ориентированный), КОП - это развитие ООП, суть статьи:
- система строиться из независимых компонентов;
- каждый компонент решает одну задачу;
- каждый компонент контекстно не зависим;
- у каждого компонента жесткий минимальный интерфейс;

От себя, разбиение системы на компоненты позволяет рассматривать её по частям, введение строго определённых интерфейсов позволяет модифицировать/развивать систему по частям.

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

P.S. А ORM всегда кривой потому что объекты их свойства и связи между ними плохо ложатся на реляционную модель.

 

[whirlwind]

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

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

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

 

[HraKK]

P.S. А ORM всегда кривой потому что объекты их свойства и связи между ними плохо ложатся на реляционную модель.

+1.

пока нашел что ООП это замедление работы + увеличение затрат на компы и что ООП не дает возможности какому-то мифическому проверщику производительности влезть в обьект, ну и смешное утрирование с фабриками.

Вот хочу спросить моя цмс на ООП, достаточно гружоная минимум мб чистого кода, всякие паттерны выдает код со скоростью 0.02-0.03, ну пусть на шареде 0.04-0.06.
То есть 16 показов в секунду или 1 миллион 382 тысячи 400 раз в сутки. Ну возьмем погрешность на пиковую загрузку 1/2 = 700 тысяч хитов в день. И это на шареде.
Стоимость 1 юнита на колокейшен - 50$ с ним я тебе покажу и 2-3 миллиона хитов. Так чтоже там за проект у которого:

стоимость владения большого веб-проекта в разы превышает фонд зп

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

Идем дальше, мифический просмотрик - а чем не устраивает Xdebug?

Ну про фабрику промолчу.

 

[fisher]

>>Стоимость 1 юнита на колокейшен - 50$ с ним я тебе покажу и
>>2-3 миллиона хитов.

как сказал бы о генри, покажите своей бабушке. никогда не будет в сосальной сети с UGC на основе php/mysql в среднем 0.02 сек на реквест. ну не работал ты с таким проектами - почему бы не послушать покорно умного дядю (это я про себя, если что), чего лезть комментировать в духе "наверное индусы писали", а? есть кардинальное отличие между проектом который отдает не меняющийся (или редко меняющийся, не персонифицированный) контент - а ты привел характерные цифры именно для такого проекта - и проектом типа вконтакте или одноклассников или жж. твои расчеты, извини, абсолютно неверные. потому что у тебя в голове - неверная модель.

>>а чем не устраивает Xdebug
потому что xdebug - на редкость бесполезная в большом проекте вещь. уровень детализации, на котором проходит оптимизация, обычно либо значительно выше, либо проходит в плоскостях, которые xdebug не затрагивает вовсе.

фиксер, скажи что-нибудь, а то ведь пионеры убьют тему сильно раньше, чем я надеялся.

 

[HraKK]

почему бы не послушать покорно умного дядю

Потому что у меня на шее есть своя башка. Давайка умный дядя, расскажи чтоже там такого общитывается в реалтайме, а? И чем тебе не понравился неменяющий контент? Я заметьте привел данные ессно без кеша, если что умный дядя.

потому что у тебя в голове - неверная модель

А у тебя верная? Можно поподробнее, а не

лезть комментировать в духе

"Сам дураг, йа умныцо!!!!11"

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

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

фиксер, скажи что-нибудь

- Мамачка, меня обижают поругай их ((

Фиксер тоже не ас в ООП, давай уж лучже зови не однодумцев, а независимых людей которые сьели собаку на ООП. А если ты хочешь услышать только, ай да молодец, ай да умница! То не понятно зачем создал тему.

 

[fisher]

HraKK, браво! Давай ещё напишем что-нибудь?

-~{}~ 15.03.09 18:11:

Автор оригинала: whirlwind
Переход с процедурного на ООП будет очень сложным даже если ты гуру лабающий проги на сях. Но болшинство таки это делает. Так какой смысл откладывать неизбежное?

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

Классический пример - сообщения, с которых всё началось. Сообщения очень хороши нужны для оповещения в ситуации когда ты знать не хзнаешт и не хочешь знать что за компоненты у тебя щас живы. Различные окна и прочие элементы интерфейса в графическом приложении - или в графической оболочке. Или какое-то конструкторское ПО - на виртуальном стенде собираешь что-то. Или игрушка, где есть сложная сцена с кучей актеров. Или 3D модель с хитрыми источниками света. Но это всё не веб! Но нет, такие красивые идеи, давайте их скорее приложим!

 

[Scud]

Чтобы всё-таки не убить тему:

итак, хочется собрать воедино - хотя бы ссылками на имеющиеся "фундаментальные" тексты - все вопросы касательно oop vs не-oop.

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

-~{}~ 15.03.09 18:29:

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

 

[HraKK]

HraKK, браво! Давай ещё напишем что-нибудь?

Слив засчитан.

 

[AmdY]

инкапсуляция как одобрение интеллектуальной слепоты

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

 

[fisher]

scud, ну тогда ещё для затравочки
http://awards.acm.org/images/awards/140/articles/4860551.pdf
(это лекция дейкстры по поводу вручения премии тьюринга в 1972 году - есть русский перевод http://khpi-iip.mipk.kharkiv.edu/library/extent/dijkstra/pp/ewd340.html)
http://bugtraq.ru/library/programming/objectshavefailed.html
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html
http://www.geocities.com/tablizer/oopbad.htm

-~{}~ 15.03.09 18:47:

>>о вообще, спор ниочём
разумеется! я лишь хотел показать, что... а, впрочем совершенно неважно - слушающий да услышит!

 

[флоппик]

лол. в интернетах опять кто то неправ...

 

[Scud]

fisher
Что мне с этим делать? Я найду время и прочту тексты, данные по линкам, но что вы хотите услышать на них, задайте вопрос, выдвиньте тезис.

 

[fisher]

Автор оригинала: Scud
fisher
Что мне с этим делать? Я найду время и прочту тексты, данные по линкам, но что вы хотите услышать на них, задайте вопрос, выдвиньте тезис.

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

 

[grigori]

fisher, респект, согласен во всем
сам пришел к этому, только не сформулировал еще так конкретно
сейчас прокомментирую подробней

-~{}~ 15.03.09 18:31:

HraKK, выложи, наконец, свою систему, создай реальный сайт с миллионом посетителей и посчитай затраты
синтетические тесты дают искуственные результаты

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

-~{}~ 15.03.09 18:35:

объектная парадигма как сладкая пища для ума - подмена

как способ упрощения мира, как попытка сильней притянуть микромир процессора и винта к привычной жизни,
уменьшить количество частиц, которые надо помнить

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

 

[HraKK]

создай реальный сайт с миллионом посетителей

Угу, конечно. Покажи мне сайт созданный тобой или fisher ( не участие, а с нуля для себя) тогда будем спорить. Мои тесты и умозрения такие же синтетические как и твои. Пока мне кто-то не покажет ошибки в теории, я не вижу смысла смотреть на практику. А заявления в стиле сделай 1 миллион - это сьезды с попыткой надавить авторитетом.

Как мне надоели эти горе оптимизаторы хайлоадеры. Если все выгорит то в скором времени покажу такой сайт, но к спору это никак не касается.

 

[grigori]

>инкапсуляция как одобрение интеллектуальной слепоты
Omne nimium nocet (лат.)
imho, безразличие к содержимому объекта является частным случаем "индусского стиля"

-~{}~ 15.03.09 18:48:

>тотальная не-математичность, не-реляционность
думаю, это обусловлено общим уровнем грамотности
высокий спрос и уровень оплаты привлекает в отрасль всех подряд, а ООП становится модой

>сам я пишу "умеренный объектный код"
я тоже последнее время стал раскрывать некоторые объекты в библиотеки функций, если вижу, что методы могут быть статическими

-~{}~ 15.03.09 18:50:

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

 

[Lightning]

fisher
Если не понимать ООП и, как следствие, использовать его неправильно, то все, что Вы писали, - правда.
Если правильно понимать и использовать ООП, то все что, Вы писали, - бред.

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

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

инкапсуляция как одобрение интеллектуальной слепоты

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

тотальная не-математичность, не-реляционность и сплошной ОРМ

ИМХО конечно, но при правильном подходе не нужен ОРМ

много мелких объектов - много операций над CPU, тормоза

Вы же сами знаете, что ресурсы жрут в основном операции обращения к БД, файлам, внешним сервисам, а вовсе не операции по созданию объектов. Зачем Вы преувеличиваете падение производительности при использовании ООП?

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

По вашему это вина ООП? Или все-таки это следствие неправильного понимания и использования ООП?

слепота, не позволяющая опуститься на "физический уровень" и думать не в пространстве монад а в пространстве утилизации конкретных имеющихся ресурсов

При нормально построенной архитектуре эти уровни разделены и никаких проблем не возникает.

 

[HraKK]

у фишера есть эти факты

В студию

 

[Lightning]

fisher
Вы назвали тему "проблемы объектного сознания", а пишете про проблемы ООП-говнокодеров.