-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
проблемы объектного сознания
- Автор темы fisher
- Дата начала
- Статус
jahson
Новичок
В ЖЖ, помнится, этот вопрос поднимался. Тестируется на раз-два. Дело в другом - синглтоны - это наше любимое глобальное состояние, причем транзитивное - оно распространяется везде, где использован синглтон. Ещё они скрывают зависимости, которые иначе могли бы быть объявлены явно. Это чревато. Легко, конечно, повесить ярлык "секта", не разглядев за маркетингом и флеймовыми темами пользы. Польза, естественно, сопряжена с дисциплиной и трудом (может странно, но так всегда) - и уж точно TDD не является решением всех проблем.
Где-то видел подобный пример про синглтоны:
Иван знает Марью, но ни Иван, ни Марья не знают Андрея. Логично для меня предположить, что если я что-то скажу Ивану, он может это пересказать Марье, но никоим образом сказанное не попадёт к Андрею. Теперь представим, что все (классы) явно объявляют некоторых своих друзей (соседние классы), но некоторых друзей оставляют скрытыми (соседние классы-синглтоны). И удивляйся потом, как Андрей узнал то, что ты сказал Ивану.
whirlwind
TDD infected, paranoid
Синглтон это отдельная песня. Синглтон - это такой же объект как и все остальные. То есть подразумевается что у него будет некоторое количество пользователей, которые будут обращаться к экземпляру через ссылку (ну или указатель). То есть пользователям наплевать сингельтон это или мульгинтон или хренгиольтон. Пользователя как всегда интересует только интерфейс. Теперь возьмите свой любимый сингельтон и замените ::getInstance на new [какой то класс] и оцените величину полученного бреда.
-~{}~ 18.03.09 08:21:
PS. кстате как раз из примера топикстартера где он жалуется на постоянное инстанцирование какойто модели. так вот ни один вменяемый оопешник никогда такого не допустит.
-~{}~ 18.03.09 08:21:
PS. кстате как раз из примера топикстартера где он жалуется на постоянное инстанцирование какойто модели. так вот ни один вменяемый оопешник никогда такого не допустит.
StUV
Rotaredom
HraKK
whirlwind
хватит цепляться к словам вне контекста
jahson
вопрос не в той или иной конкретной технологии или тонкостях реализации
неизвестно что было в целях тредстарта, но в итоге оно грохнуло сумбурным потоком мыслей по "закостенелым умам", привыкшим мыслить в рамках лидирущей последние 25 лет парадигмы и привело к бурному флейму с полным взаимным непониманием и все-таки различным мнениям и в среде сторонников общих напроавлений/подходов
никто не спорит, что польза есть
есть достоинства, преимущества, достижения, но есть и недостатки
недостатки не "в сравнении с ...", а просто, "нативные, собственные недостатки"
и проблема объектного мышления это не только проблема мыслящего субъекта, но и проблема объекта мысли
нежелание отложить "привычное, полезное, единственно верное" средство, подумать о возможных недостатках... вызывает появление в треде слов "ярлык", "секта" и т.п...
но не конкретика деталей
хотя да, с них все начинается - не по отдельности, а в совокупности
-~{}~ 18.03.09 08:54:
добавлю что... - технология формулируемая в терминах абстракций мышления в приложении к абстракциям области действия уходит в рекурсию самодостаточности решений, для выхода из которой требуются эмпирически подтверждаемые, но неформулируемые в рамках сферы формулирования, дополнительные средства
что в теории развития наук обычно является предпосылкой к заметному эволюционному скачку технологии или появлению новой
whirlwind
хватит цепляться к словам вне контекста
jahson
вопрос не в той или иной конкретной технологии или тонкостях реализации
неизвестно что было в целях тредстарта, но в итоге оно грохнуло сумбурным потоком мыслей по "закостенелым умам", привыкшим мыслить в рамках лидирущей последние 25 лет парадигмы и привело к бурному флейму с полным взаимным непониманием и все-таки различным мнениям и в среде сторонников общих напроавлений/подходов
никто не спорит, что польза есть
есть достоинства, преимущества, достижения, но есть и недостатки
недостатки не "в сравнении с ...", а просто, "нативные, собственные недостатки"
и проблема объектного мышления это не только проблема мыслящего субъекта, но и проблема объекта мысли
нежелание отложить "привычное, полезное, единственно верное" средство, подумать о возможных недостатках... вызывает появление в треде слов "ярлык", "секта" и т.п...
но не конкретика деталей
хотя да, с них все начинается - не по отдельности, а в совокупности
-~{}~ 18.03.09 08:54:
добавлю что... - технология формулируемая в терминах абстракций мышления в приложении к абстракциям области действия уходит в рекурсию самодостаточности решений, для выхода из которой требуются эмпирически подтверждаемые, но неформулируемые в рамках сферы формулирования, дополнительные средства
что в теории развития наук обычно является предпосылкой к заметному эволюционному скачку технологии или появлению новой
jahson
Новичок
Неизвестно, да. Сумбурно - очень точно. Про лидерство - не знаю. Где-то, наверное да, где-то - нет. Флейм будет неизбежен при подобных постановках вопросов и ответов - такова природа человека, это нужно понимать, особенно заводя такую тему. Про преимущества и недостатки я там раньше писал - я не вижу ни в одном подходе кардинального преимущества. И это нормально, я думаю.
Что имелось в виду под проблемой "объектного мышления" я до сих пор не могу понять. Про увлечённость процессом - я писал чуть раньше, это проблема более общая.
Привычных, полезных и единственно верных средств у меня нет. У меня есть инструменты и я постоянно смотрю на недостатки и пытаюсь их исправить или облегчить последствия.
StUV
Rotaredom
ну так... твоими же словами - с моими каментами =)
-
в современных системах последние в значительной степени превалируют над первыми - соответственно и этого
становится все больше и оно часто прикрывает "отправную точку"
хорошо это или плохо - вопрос другой
но все-таки хотелось бы в этом разобраться досконально, а не "делай, потому что оно работает"
а для понимания тонкостей проблемы - да, проще всего развести острый флейм на около-аналитические темы типа "ооп vs. функции" и пытаться постепенно подвести к "отсутствующему противоречию"
и да
согласен, но где-то эта проблема решается математически точно (тупой рационализм оптимизации трейсов), а где-то оптимизированная структура не имеет функций обратной трансформации в пространство категорий приложения
svetasmirnova
маленький монстрик
x-yuri
> svetasmirnova, а где я указал на вменяемых людей? Религиозное отношение к программированию обязывает к написанию невменяемого кода.
Ты сказал, что это минус объектного подхода. А объектный подход не навязывает паттернов.
Про то что "невменяемые" люди пишут при любом подходе можно много экранов понаписать. Тем не менее это не будет минусом никакого подхода.
> svetasmirnova, предположу, что речь об Linux: C++ In The Kernel?, Why don't we rewrite the Linux kernel in C++?
Ты сам-то читал что там написано?
Вот пара цитат: "you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++." и "Should the kernel use object-oriented programming techniques? Actually, it already does. The VFS (Virtual Filesystem Switch) is a prime example of object-oriented programming techniques. There are objects with public and private data, methods and inheritance. This just happens to be written in C. Another example of object-oriented programming is Xt (the X Intrinsics Toolkit), also written in C. What's important about object-oriented programming is the techniques, not the languages used."
И вообще ответ именно на этот свой вопрос я хотела бы услышать от Lightning.
> svetasmirnova, а где я указал на вменяемых людей? Религиозное отношение к программированию обязывает к написанию невменяемого кода.
Ты сказал, что это минус объектного подхода. А объектный подход не навязывает паттернов.
Про то что "невменяемые" люди пишут при любом подходе можно много экранов понаписать. Тем не менее это не будет минусом никакого подхода.
> svetasmirnova, предположу, что речь об Linux: C++ In The Kernel?, Why don't we rewrite the Linux kernel in C++?
Ты сам-то читал что там написано?
Вот пара цитат: "you can write object-oriented code (useful for filesystems etc) in C, _without_ the crap that is C++." и "Should the kernel use object-oriented programming techniques? Actually, it already does. The VFS (Virtual Filesystem Switch) is a prime example of object-oriented programming techniques. There are objects with public and private data, methods and inheritance. This just happens to be written in C. Another example of object-oriented programming is Xt (the X Intrinsics Toolkit), also written in C. What's important about object-oriented programming is the techniques, not the languages used."
И вообще ответ именно на этот свой вопрос я хотела бы услышать от Lightning.
svetasmirnova
маленький монстрик
> это детали. И то, и другое провоцирует отрыв от реальности в сравнении с процедурным подходом, имхо
Ты почитай книжку. Вступление хотя-бы. Паттерны из реальных проектов появились.
Ты почитай книжку. Вступление хотя-бы. Паттерны из реальных проектов появились.
StUV
Ты очень прав и большой тебе респект, проблема в том что некоторые типа fisher и ко как раз не считают
Еслиб тема была такая: ООП и его недостатки, и не было бы контекста проц рулит, а ООП гавно, не было бы такое флейма и непонимания.
А ведь именно так и есть. Вот мы сейчас успешно под руководством Long отказываемся от ООП, в сторону процедурного(на классах) кода потому что под ООП проект загнется так как ооп тормоз! ПТЫЩЬ.
П.С. правда после того как я посмотрел на код, я понял почему мы отказываемся от ООП.
Ты очень прав и большой тебе респект, проблема в том что некоторые типа fisher и ко как раз не считают
Ясен хрен что недостатки есть. Они считают что изза этих недостатковв надо в большинстве случаев отказыватся от ООП, а процедурный рулит. Скажешь нет?
Еслиб тема была такая: ООП и его недостатки, и не было бы контекста проц рулит, а ООП гавно, не было бы такое флейма и непонимания.
А ведь именно так и есть. Вот мы сейчас успешно под руководством Long отказываемся от ООП, в сторону процедурного(на классах) кода потому что под ООП проект загнется так как ооп тормоз! ПТЫЩЬ.
П.С. правда после того как я посмотрел на код, я понял почему мы отказываемся от ООП.
svetasmirnova
маленький монстрик
HraKK
> П.С. правда после того как я посмотрел на код, я понял почему мы отказываемся от ООП.
На чей/какой код?
> П.С. правда после того как я посмотрел на код, я понял почему мы отказываемся от ООП.
На чей/какой код?
svetasmirnova
Еще одного разработчика у нас в комманде. Код в котором в фасаде описывается вся логика + sql запросы в нем же. Конечно же с иньекциями. Гениальные индуские действия местами, а exсeption это не круто, намного круче @! Конечно же во всем виноваты проблемы объектного сознания, вы чо!
Еще одного разработчика у нас в комманде. Код в котором в фасаде описывается вся логика + sql запросы в нем же. Конечно же с иньекциями. Гениальные индуские действия местами, а exсeption это не круто, намного круче @! Конечно же во всем виноваты проблемы объектного сознания, вы чо!
svetasmirnova
маленький монстрик
HraKK
Ты что? @ - это же крутняк!
О! Кстати. Я тут меряла сколько собаки отжирают, так что невозможность использовать исключения при процедурном подходе в PHP одновременно с необходимостью пользоваться фунциями типа mysql_query - такой +1 в пользу ООП в проекте. Хотя, с другой стороны, обработчик ошибок есть и в ООП его всё равно испозовать придётся, если хочется исключений встроенных функций
Вопрос к процедурщикам: а как вы с run-time errors обходитесь? С исключениями ведь гибко очень: можно обработать на любом этапе без бесконечных if(false === some_func()) { ... } Меня вот это очень задалбывает.
Ты что? @ - это же крутняк!
О! Кстати. Я тут меряла сколько собаки отжирают, так что невозможность использовать исключения при процедурном подходе в PHP одновременно с необходимостью пользоваться фунциями типа mysql_query - такой +1 в пользу ООП в проекте. Хотя, с другой стороны, обработчик ошибок есть и в ООП его всё равно испозовать придётся, если хочется исключений встроенных функций
Вопрос к процедурщикам: а как вы с run-time errors обходитесь? С исключениями ведь гибко очень: можно обработать на любом этапе без бесконечных if(false === some_func()) { ... } Меня вот это очень задалбывает.
svetasmirnova
маленький монстрик
StUV
Ассерт это тот же if(false === some_func()) { ... }. А про триггеры и хэндлеры я сказала, но опять-таки это только глобально. А я хочу иметь возможность вообще не смотреть на возвращаемые значения (которые из-за ошибок) в части кода и сразу возвращать пользователю ошибку с записью в лог, в другой их обрабатывать сразу же, в третьей отложить до времени. Плюс нюансы.
-~{}~ 18.03.09 15:55:
whirlwind
> Кстате, создатели java почему-то с тобой не согласятся
Создатели Java считают, что if(false === some_func()) { ... } более гибкая вещь, чем исключения?
Ассерт это тот же if(false === some_func()) { ... }. А про триггеры и хэндлеры я сказала, но опять-таки это только глобально. А я хочу иметь возможность вообще не смотреть на возвращаемые значения (которые из-за ошибок) в части кода и сразу возвращать пользователю ошибку с записью в лог, в другой их обрабатывать сразу же, в третьей отложить до времени. Плюс нюансы.
-~{}~ 18.03.09 15:55:
whirlwind
> Кстате, создатели java почему-то с тобой не согласятся
Создатели Java считают, что if(false === some_func()) { ... } более гибкая вещь, чем исключения?
svetasmirnova
маленький монстрик
Кстати добавлю-ка я ремарку. Для Long и людей с подобными мнениями.
Не забывайте, что формула "процедурный подход при умелом подходе - быстрый код" может быть справедливой только для PHP и подобных языков. Существуют окружения, где ОО-подход будет работать в разы быстрее, чем процедурный. Знакомый всем пример, который широко используется в web, - JavaScript.
А PHP ничего никому не навязывает, каждый может делать как угодно, за что его и любим А то получается вроде как всё подряд обсуждаем, а на самом нет.
-~{}~ 18.03.09 16:04:
whirlwind
> компилятор требует сетку в вызывающем коде
Что такое сетка? try {} catch ()?
Не забывайте, что формула "процедурный подход при умелом подходе - быстрый код" может быть справедливой только для PHP и подобных языков. Существуют окружения, где ОО-подход будет работать в разы быстрее, чем процедурный. Знакомый всем пример, который широко используется в web, - JavaScript.
А PHP ничего никому не навязывает, каждый может делать как угодно, за что его и любим
А то получается вроде как всё подряд обсуждаем, а на самом нет.-~{}~ 18.03.09 16:04:
whirlwind
> компилятор требует сетку в вызывающем коде
Что такое сетка? try {} catch ()?
StUV
Rotaredom
svetasmirnova
семантически - просто разная форма записи
точно так же и exception vs. assert-arg
у тебя может быть
if (bool|int), а может и my_assert(struct)
другое дело, что ооп-шный вариант "удобоваримее"
ну и
-~{}~ 18.03.09 16:25:
т.е. trigger и if (...)/assert=>{...} - это "унылое г.", а throw и catch(...)=>{...} - это круто ?
семантически - просто разная форма записи
точно так же и exception vs. assert-arg
у тебя может быть
if (bool|int), а может и my_assert(struct)
другое дело, что ооп-шный вариант "удобоваримее"
ну и
а в catch() у тебя что ?
-~{}~ 18.03.09 16:25:
создатели считают, что если тебе не нужен полный контроль обработки исключений на уровне компилятора - ты можешь его отключить в точке входа через "throws Throwable" =)
- Статус