-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
проблемы объектного сознания
- Автор темы fisher
- Дата начала
- Статус
fisher
знаешь, я тут сознательно пошел на эксперимент с более-менее полным ООП в проекте по типу соцсети. Все понятно будет через месяц, когда запустим, а точнее еще через пару месяцев когда траф нагоним, но сейчас можно что сказать.
1. Время на создание мелких объектов - это по большому счету миф. Трейс автолоада уже не помещается на экран и при этом время на создание объектов сопоставимо с временем запроса к мемкешу. Больше всего из апп-логики жрет сейчас сам хитрый автолоад, который в продакшене будет заменен на статическую карту. Конечно некоторый оверхед есть, но он очень далек от того чтобы стать боттлнеком.
2. Итак, мелкого дробления перестали бояться. При достаточной детализации и "говорящих" именах методов проблема вида "дергаем хрен знает что из модели" вполне себе решается. Решаем так - диспетчер странцы работает не непосредственно с моделью, а с "объектом сущности" - пользователь, фотка итд. Со своей моделью (или своими моделями) работает только он непосредственно, для разных действий есть разные методы. Тут грубая аналогия с денормализацией в БД - вводится избыточность. Конечно, понимать, что какой метод делает, надо, но это опять же решается дроблением.
3. Главное - устаканить "внешний" (с точки зрения тех кто клепает странички) интерфейс. На рефакторинг внутренностей приходится уделять время, но методика "придумать внешний интерфейс, наклепать абы как, и, пока люди уже с этим работают, отрефакторить и оптимизировать нутря" работает вполне (вообще это получается ТДД с выброшенным первым шагом "написать тест", точнее упрощенным до "прикинуть как оно там будет", ну и в качестве теста работают уже потом странички. С тдд чутка поэкспериментировали но не прижилось и сдохло в зародыше, не исключаю что ниасилили). Главное тут, разделить правильно обязанности, влезть внутрь чужих интерналсов и дописать что-то "потому что мне надо" без обсуждения просто запрещается, за это по рукам, иначе будет помойка.
4. Типичную для такого рода приложений проблема "веб-контекстых синглтонов" (в страничках нужен один экземпляр, в скриптах - сколько угодно) решаем "веб-контекстными фабриками", наверняка есть какой то паттерн с правильным названием, суть - фабрика с графом "ленивой" инициализации. Грубо говоря WebPage :: $this->Context->User подгрузит по необходимости вызовом цепочки методов веб фабрики" сессию, сайтконфиг, локаль итд, при этом в контексте скрипта таких вещей просто нет.
5. Формы, урлы и пр. view-related - через хелперы (fisher - спасибо за багофичу в blitz с возможностью написания колбэка в форме {{ foo.bar() }}, очень удобно
). Кстати "гуевый" MVC оказался применим и в вебе, идея с $User->renderTo($View), $Photo->renderTo($View) etc оказалась очень продуктивной, я прикрываясь Фаулером и всячески ее защищая, ее вводил с огромной опаской, но получилось клево.
В итоге недели три ушло на устаканивание апи и пресечение бесконечных споров, зато действительно странички клепаются быстро, вот сейчас посмотрел в траке, страничка настроек - время от написания до закрытия тикета полчаса, реальное время разработки думаю минут 15.
Теперь если говорить о теоретической стороне, fisher - ну вот что еще у тебя там в ЖЖ было с математикой - так то что некоторые противопоставляют ООП и процедурный подход это в корне неверно, процедурный он никуда не девается, он остается внутри класса. А публичные методы - это интерфейс. Вот у проигрывателя внутри своя математика и свои функции, у усилителя свои, а соединяются они через интерфейсный кабель) примерно такая аналогия.
знаешь, я тут сознательно пошел на эксперимент с более-менее полным ООП в проекте по типу соцсети. Все понятно будет через месяц, когда запустим, а точнее еще через пару месяцев когда траф нагоним, но сейчас можно что сказать.
1. Время на создание мелких объектов - это по большому счету миф. Трейс автолоада уже не помещается на экран и при этом время на создание объектов сопоставимо с временем запроса к мемкешу. Больше всего из апп-логики жрет сейчас сам хитрый автолоад, который в продакшене будет заменен на статическую карту. Конечно некоторый оверхед есть, но он очень далек от того чтобы стать боттлнеком.
2. Итак, мелкого дробления перестали бояться. При достаточной детализации и "говорящих" именах методов проблема вида "дергаем хрен знает что из модели" вполне себе решается. Решаем так - диспетчер странцы работает не непосредственно с моделью, а с "объектом сущности" - пользователь, фотка итд. Со своей моделью (или своими моделями) работает только он непосредственно, для разных действий есть разные методы. Тут грубая аналогия с денормализацией в БД - вводится избыточность. Конечно, понимать, что какой метод делает, надо, но это опять же решается дроблением.
3. Главное - устаканить "внешний" (с точки зрения тех кто клепает странички) интерфейс. На рефакторинг внутренностей приходится уделять время, но методика "придумать внешний интерфейс, наклепать абы как, и, пока люди уже с этим работают, отрефакторить и оптимизировать нутря" работает вполне (вообще это получается ТДД с выброшенным первым шагом "написать тест", точнее упрощенным до "прикинуть как оно там будет", ну и в качестве теста работают уже потом странички. С тдд чутка поэкспериментировали но не прижилось и сдохло в зародыше, не исключаю что ниасилили). Главное тут, разделить правильно обязанности, влезть внутрь чужих интерналсов и дописать что-то "потому что мне надо" без обсуждения просто запрещается, за это по рукам, иначе будет помойка.
4. Типичную для такого рода приложений проблема "веб-контекстых синглтонов" (в страничках нужен один экземпляр, в скриптах - сколько угодно) решаем "веб-контекстными фабриками", наверняка есть какой то паттерн с правильным названием, суть - фабрика с графом "ленивой" инициализации. Грубо говоря WebPage :: $this->Context->User подгрузит по необходимости вызовом цепочки методов веб фабрики" сессию, сайтконфиг, локаль итд, при этом в контексте скрипта таких вещей просто нет.
5. Формы, урлы и пр. view-related - через хелперы (fisher - спасибо за багофичу в blitz с возможностью написания колбэка в форме {{ foo.bar() }}, очень удобно
). Кстати "гуевый" MVC оказался применим и в вебе, идея с $User->renderTo($View), $Photo->renderTo($View) etc оказалась очень продуктивной, я прикрываясь Фаулером и всячески ее защищая, ее вводил с огромной опаской, но получилось клево.В итоге недели три ушло на устаканивание апи и пресечение бесконечных споров, зато действительно странички клепаются быстро, вот сейчас посмотрел в траке, страничка настроек - время от написания до закрытия тикета полчаса, реальное время разработки думаю минут 15.
Теперь если говорить о теоретической стороне, fisher - ну вот что еще у тебя там в ЖЖ было с математикой - так то что некоторые противопоставляют ООП и процедурный подход это в корне неверно, процедурный он никуда не девается, он остается внутри класса. А публичные методы - это интерфейс. Вот у проигрывателя внутри своя математика и свои функции, у усилителя свои, а соединяются они через интерфейсный кабель
) примерно такая аналогия.
fixxxer
Молодец.
Кстати я тут недавно для домохозяек писал заметку можете и почитать:
http://correct.com.ua/ru/interesting/highload
Молодец.
Кстати я тут недавно для домохозяек писал заметку можете и почитать:
http://correct.com.ua/ru/interesting/highload
Но кстати та проблема что любой сходу написанный ООП код получится х*евый никуда не девается. Просто не надо ее бояться, надо устаканить вменяемый внешний АПИ а нутря по необходимости рефакторить
-~{}~ 15.03.09 21:15:
Кстати скрам у нас в его каноническом виде тоже почти сдох, практически перетек в постоянное живое общение, а спринты практически выдерживаются и без их объявления =)
-~{}~ 15.03.09 21:15:
Кстати скрам у нас в его каноническом виде тоже почти сдох, практически перетек в постоянное живое общение, а спринты практически выдерживаются и без их объявления =)
fisher
накатила суть
Смотрите что Вы делаете. Вместо того, чтобы рассматривать объективно проблемы - Вы аггресивно нападаете. Нехорошо. Впрочем, рассмотрим аргументы подробнее.
Праздник к нам приходит! Мозги позволяют спроектировать гибкий код, в котором нет дублирования, а не паттерны. Смотрите глубже - смотрите на паттерны как на культурный феномен! С точки зрения языка как средства выражения мыслей паттерны - это вынужденный протокол. Вынужденный! Когда "состояние" и "поведение" совмещены, бывает сложно придумать общий формат описания совместного взаимодействия - приходится вводить регламент, называемый в простонародьи паттернами. Как штаны заправлять, как ложку держать.
Для чего нужна инкапсуляция я, как Вы вероятно, догадываетесь, знаю. Я говорю о том, к чему она приводит - психологически.
Не мои слова - если не смотрели приведенные мной ссылки - Ричард П. Гэбриэл: "предполагалось, что такие мощные концепции, как инкапсуляция, должны спасти людей от самих себя при разработке программ, но инкапсуляция не срабатывает в ситуациях, где необходимо использовать глобальные свойства, или когда необходимо развитие программы или ее коренная перестройка. Концепция открытого исходного кода лучше справляется с подобной ситуацией. Похоже, что только модульность — разбиение на составные части так, чтобы люди могли их понять — вот что действительно важно в инкапсулировании"
Вот и расскажите об этом коллегам. А ещё расскажите, почему.
Вы ошибаетесь касательно ресурсов, и сильно. Есть некий уровень зрелости у веб-проекта, когда он упирается в CPU на вебах. Когда всё уже затюнено по самые не балуйся. Это вот самые-самые первные шаги к пониманию - думать, что "ресурсы жрут в основном операции обращения к БД, файлам, внешним сервисам". Дальше. Хороший программист - что на объектном языке, что на другом - сможет сделать "всё правильно". Но язык не объектный просто не провоцирует создавать "тяжелые" конструкции. Конечно, зависит и от реализации объектного языка. Но желание написать $объект->делайЧтоТо() оно уже укореняется в мозгу настолько, что ты даже не думаешь, что делает машина, когда выполняет компилированный код, где вместо прозрачной работы с данными компилятор потел-возился-опитимизировал твой код с кучей твоих мелких объектов туда-сюда что-то дергающих, передающих и зовущих. В пхп я вообще молчу что случается от множества таких конструкций. Снова, всё в принципе решаемо, умные компиляторы - но язык и парадигма провоцируют. Объектная парадигма в большой степени провоцирует не думать на физическом уровне - не думать про то, что скрывается за. Классический пример приводил я как-то подслушал на java user group сборище - спроектировать свой мирок "правильно" так, что интерфейс взаимодействия компонент исключает пакетную обработку (обработка пакета сообщений вместо "пакета" последовательного вызова обработчика для одного сообщения). Но снова - вы можете наступить на такие грабли и при любом другом подходе.
Простите, это демагогия. "У меня всё работает!"
С "герменевтической" точки зрения, та модель, которая строится в объектной парадигме при помощи объектных же кирпичиков, коих много разных, и ньюансов языковых много разных, и всяких трюков и паттернов полно (и вспоминаем многочистенные идиотские загадки про последовательность вызовов конструкторов, про виртуальные конструкторы и так далее - весь этот бред, это знание бесполезное и никчемное) - вот вся эта адская смесь видится мне обладающей интеллектуальной мощностью, достаточной, чтобы очень сильно отвлекать разработчика от реальной жизни. Разработчик строит модели, творит, и часто забывает - для чего. Это проблема любого разработчика на каком бы языке он ни писал - но чем богаче поле для умственной деятельности, тем больше шансов решить не ту задачу, которая требовалась, а ту, которую он себе придумал сам.
>> Ну так а кто с тобой спорит?
Я.
Если вебы начнут дохнуть как котята, я вот сюда притопаю и признаю что был не прав. Но пока по бенчмаркам не вижу тому причин. А если нам понадобится вместо 50-и вебов 53 и при этом я сэкономлю пару месяцев времени разработки и еще кучу на сопровождение, я буду считать что я прав =)
-~{}~ 15.03.09 22:01:
Кстати вот подумал, что если уж так рассуждать, что надо экономить каждую миллисекунду CPU time, то надо отказываться от РСУБД и юзать berlkey db =) примерно такие же аргументы можно привести. Я все же полагаю что разумнее искать компромисс между затратами на человекочасы и железо. С другой стороны, коэффициенты, на которые умножаются сии показатели, зависят от масштабов. Мы то не претендуем на лавры фейсбука, я рассуждаю масштабами скажем мамбы трехлетней давности, а прогнозируя рост принимая во внимание закон Мура =)
Я.
Если вебы начнут дохнуть как котята, я вот сюда притопаю и признаю что был не прав. Но пока по бенчмаркам не вижу тому причин. А если нам понадобится вместо 50-и вебов 53 и при этом я сэкономлю пару месяцев времени разработки и еще кучу на сопровождение, я буду считать что я прав =)
-~{}~ 15.03.09 22:01:
Кстати вот подумал, что если уж так рассуждать, что надо экономить каждую миллисекунду CPU time, то надо отказываться от РСУБД и юзать berlkey db =) примерно такие же аргументы можно привести. Я все же полагаю что разумнее искать компромисс между затратами на человекочасы и железо. С другой стороны, коэффициенты, на которые умножаются сии показатели, зависят от масштабов. Мы то не претендуем на лавры фейсбука, я рассуждаю масштабами скажем мамбы трехлетней давности, а прогнозируя рост принимая во внимание закон Мура =)
fisher
накатила суть
посмотрим когда ты ещё это поподдерживаешь пару-тройку лет
Справедливости ради, я соглашусь, что надо постараться в веб-скрипте засрать кучей объектов CPU. Но снова - в том же PHP код изобилующий объектными обращениями часто добавляет немало пляски по стеку вызовов + хэш-лукапы. Нафиг надо?
Согласен - но по-моему это не имеет ничего общего с обсуждаемой темой
Мне это всё что-то напоминает
У нас если помнишь попытка позвать юзер через контекст из скрипта приводила к соответствующей ошибке.Но вообще что ты пишеш - это скорее "правильная практика". Понимаешь, до неё ж ещё допереть надо, поломав кучу ребер и конечностей.
эээ а подробнее?Автор оригинала: fixxxer
5. Формы, урлы и пр. view-related - через хелперы (fisher - спасибо за багофичу в blitz с возможностью написания колбэка в форме {{ foo.bar() }},
очень удобно
Знаешь, мне кажется, ты не совсем понял, о чём я писал: я писал о проблеме языка - мы вдруг перестаем говорить на старых языках (координаты и закон движения - это разные крючки) и говорим на каком-то новом, в котором "состояние" и "поведение" совмещены в сущностях окончательно и бесповоротно.Автор оригинала: fixxxer
Теперь если говорить о теоретической стороне, fisher - ну вот что еще у тебя там в ЖЖ было с математикой - так то что некоторые противопоставляют ООП и процедурный подход это в корне неверно, процедурный он никуда не девается, он остается внутри класса. А публичные методы - это интерфейс. Вот у проигрывателя внутри своя математика и свои функции, у усилителя свои, а соединяются они через интерфейсный кабель
fisher
накатила суть
я хочу с тобой поспорить, потому что ты думаешь, что "ооп ришает реальни". я же говорю что ооп не решает - чаще наоброт, лишь сбивает с толку. с точки зрения банальной эрудиции твой биллинг - это данные и работа с ними. его можно написать как угодно, чтобы он не загнулся, в любой парадигме. и в любой же парадигме его можно превратить в треш.
Посмотрим, да.
Я все же стараюсь мыслить оптимистически Ну и кстати говоря, при детализованной на уровне вызовов небольих методов небольших классов xdebug-овский трейс выглядит уже вменяемо, хотя все равно надо думать как это грамотно фильтровать и наглядно представлять - и самое интересное агрегировать.Я кстати перечитал, да там половина поста не имеет общего. Остапа несло =) Но все таки косвенно имеет.
Ага, это учли, и именно поэтому скриптовый контекст не имеет никаких сущностей, кроме совсем общих (логгер, реквест и респонс). Нужно что в скрипте - извольте инстанциировать.
Это да. То что сейчас получилось это уже третья попытка, то, что в предыдущих двух проектах, мне уже совсем не нравится
и опыт сын ошибок трудных и все такое.foo.bar -> Blitz::__call() -> HelperClass->HelperMethod
ну и еще хитрый патч, включающий передачу текущего, мм, контекста (то есть видимых в шаблоне переменных) первым параметром - примерно так как я тебе тогда писал только без явного указания параметра - просто устанавливается такой режим для инстанса Blitz. Немножко перезаморочено, зато например формочки делаются так:
PHP:
{{ form.begin('foo') }} // если опущено, то default - указывает на каталог с шаблонами форм
{{ form.input('element-name' [ , 'class' ] ) }}
{{ form.end() }}>> я писал о проблеме языка - мы вдруг перестаем говорить на старых языках (координаты и закон движения - это разные крючки) и говорим на каком-то новом, в котором "состояние" и "поведение" совмещены в сущностях окончательно и бесповоротно
Осталось решить хорошо это или плохо =) Такой переход, кстати, в технике применяется давно. Например, функционально-стоимостный анализ <http://ru.wikipedia.org/wiki/ФСА> по сути оперирует объектами.
fisher
накатила суть
карасиво, да, но с таким же успехом ты мог использовать и любой helper('method', params). то есть я не очень вижу разницы кроме красивой записи.Автор оригинала: fixxxer
foo.bar -> Blitz::__call() -> HelperClass->HelperMethod
Тут есть один важный ньюанс - объекты в ФСА вполне себе осязаемы, по большому счету это обратная задача, реконструкция компонент, то есть в унисон с компонентным подходом в электронике. Успех ФСА отчасти определен успехом на то момент "нового" промышленного метода сборки чего-то сложного из базовых компонент (вспоминаем первые автомобили и конвеер форда - сейчас всё что ни возьми это плата + какая-то начинка понатыканная поверх + софт). То есть граничные условия благоприятные. В абстрактной задаче всё сложнее. С другой стороны, со временем возможнго для многих задач, которые мы сейчас решаем впервые изобретая свои велосипеды - затем будут готовы соответствующие "объектные" компоненты. С точки зрения промышленного производства объектная парадигма "удобная" - поэтому я и писал про коммерческую заинтересованность.
Кстати это же рефакторинг! Условно и грубо декомпозиция спагетти-кода приводит к построению копмонентной архитектуры.
Кстати если отойти в сторону, я вообще считаю что разработка основанная на компонентах в любой области коммерчески очень привлекательна. Вот те же VB/Delphi вспомни. Для веба такого пока ничего вменяемого нет, и думаю потому, что десктопные интерактивные решения пытаются тупо перенести в stateless веб.
-~{}~ 15.03.09 22:50:
А понятность и наглядность шаблона для верстальщика я считаю очень важной штукой. Вот тут недавно взяли нового, он за пару часов врубился без особых объяснений. В этом плане кстати всякие RoR и Симфони это ужас-ужас, шаг в сторону и начинаются свистопляски с программированием в шаблоне.
-~{}~ 15.03.09 22:54:
Больно много у меня "кстати", надо переходить на "например" =)
Условно и грубо декомпозиция спагетти-кода приводит к построению копмонентной архитектуры.Кстати если отойти в сторону, я вообще считаю что разработка основанная на компонентах в любой области коммерчески очень привлекательна. Вот те же VB/Delphi вспомни. Для веба такого пока ничего вменяемого нет, и думаю потому, что десктопные интерактивные решения пытаются тупо перенести в stateless веб.
-~{}~ 15.03.09 22:50:
А понятность и наглядность шаблона для верстальщика я считаю очень важной штукой. Вот тут недавно взяли нового, он за пару часов врубился без особых объяснений. В этом плане кстати всякие RoR и Симфони это ужас-ужас, шаг в сторону и начинаются свистопляски с программированием в шаблоне.
-~{}~ 15.03.09 22:54:
Больно много у меня "кстати", надо переходить на "например" =)
whirlwind
TDD infected, paranoid
Ключевым моментом было не написать, а сопровождать, то есть неоднократно модифицировать. Я не представляю как в процедурном стиле добавить новый алгоритм проведения транзакции в банке при сохранении кода алгоритма проведения ее же по биллингу. Ну к примеру 20 банков в системе. Ничего кроме switch/if/else я представить не могу. Приведи вариант который будет так же удобен как factory в продакшене и в тестировании и я признаюсь что был не прав.
Это как водить автомобиль. Вот ты пишешь - умеренно (т.е. частично) использую ООП. Как это частично? Ты либо умеешь водить автомобиль либо не умеешь. Не бывает умеренного или неумеренного умения вождения автомобиля. Умение нажимать на педаль газа не канает за умение водить. Или например по гравию ты ездить умеешь, а по асфальту нет. Ну не бывает такого. Вот если бы ты сказал я акуенно шарю в ООП, я знаю почему ассоциативные массивы, магические функции, статика и блоки кода длинее 20 строк - это зло, а тайп хинтинг, эксепшены, паттерны, TDD - это круто. Вот тогда бы можно и поспорить.
fisher
накатила суть
так эта... машина тьюринга же! код ядра линукс например - хороший пример. всё что может быть реализовано на объектном языке - скорее всего может быть реализовано и на нормальном процедурном. если это не фортран, конечно (хотя черт его знает!). в твоем примере замена switch - ну например "указатели на функции" (пишу в кавычках, потому что в разных языках эта концепция выглядит по-разному).
Не бывает "зла" вне контекста. Ты противопоставляешь ООП "ассоциативные массивы, магические функции, статика и блоки кода длинее 20 строк". Есть такой метод спора: подменить точку зрения оппонента чем-то другим и опровергнуть
Но даже в этом стремлении - ну как можно опровергнуть "ассоциативные массивы" !А умеренно - не означает частично. Умеренно означает не пихать ООП там, где есть более простые, понятные и эффективные способы решения задачи. И кстати - вот тотальное желание примененить "объектный" подход всегда и везде - вот это лишнее подтверждение моим словам - мы получили целую вселенную, хотя это всего лишь вагон метро, чтобы доехать до дому, а выйти надо было ещё на прошлой остановке.
whirlwind
TDD infected, paranoid
Ну а смысл обсуждать какой то есть, если преимущества познаются только в процессе эксплуатации? Это примерно как обсуждать вкус мороженного с человеком который ни разу его не пробовал, не находите Тут уж либо на веру либо никак. Я хочу сказать только одно - лично для меня ООП это стиль мышления который лично мне позволяет эффективно решать задачи в том числе те, которые возникнут в перспективе. ООП это язык который позволяет мне общаться с членами команды на уровне интуитивно воспринимаемых абстракций.
-~{}~ 16.03.09 00:09:
ЗЫ. ну так мы упираемся снова в ассемблер. а чо ваще ассемблер я помню на спектруме вообще в хексах программы вбивали. смысл написания программы не задрочиться а решить задачу с минимальными затратами.
Тут уж либо на веру либо никак. Я хочу сказать только одно - лично для меня ООП это стиль мышления который лично мне позволяет эффективно решать задачи в том числе те, которые возникнут в перспективе. ООП это язык который позволяет мне общаться с членами команды на уровне интуитивно воспринимаемых абстракций.-~{}~ 16.03.09 00:09:
ЗЫ. ну так мы упираемся снова в ассемблер. а чо ваще ассемблер я помню на спектруме вообще в хексах программы вбивали. смысл написания программы не задрочиться а решить задачу с минимальными затратами.
- Статус