Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 107
Пощюпать дадите?
Боюсь, как бы за пиар своего движка не восприняли.
Вышлю в личку ссылку на гитхаб.
Вышлю в личку ссылку на гитхаб.
Думаю это будет оптимальный вариант.
А мне вышлете? :)
Кстати, в PHP 5.3 появились неймспейсы, так что глобальность можно вычеркнуть из минусов. По той же причине, можно не тратить время на запихивание анонимных функций в синглетон.
Кстати, в PHP 5.3 появились неймспейсы, так что глобальность можно вычеркнуть из минусов. По той же причине, можно не тратить время на запихивание анонимных функций в синглетон.
Глобальность еще в том моменте плоха, что можно вызвать функцию в обход класса-синглтона, что как-то некорректно.
Вышлю, но предупреждаю, что для своей системы, лучше реализовывать самому, всё-таки архитектуры разные.
Вышлю, но предупреждаю, что для своей системы, лучше реализовывать самому, всё-таки архитектуры разные.
Естественно. Мне просто хотелось взглянуть, и не зря. Ваш код действительно интересно изучать: все эти сокращения, необычные решения… throw new WTF('Unknown Application... — доставило :)
Сокращения, магия и ниндзя-код, как раз то, что останавливает меня от пиара и публичности.
Кстати, обработчики исключений, тоже можно реализовывать через этот механизм, что позволяет навешивать хендлеры через конфиг, или сделать удобную админку, с чекбоксами: вот для этого высылать письмо админу, а вот здесь нет.
ЗЫ Я не оценил необходимости множества классов — исключений, потому WTF мне хватает =)
Кстати, обработчики исключений, тоже можно реализовывать через этот механизм, что позволяет навешивать хендлеры через конфиг, или сделать удобную админку, с чекбоксами: вот для этого высылать письмо админу, а вот здесь нет.
ЗЫ Я не оценил необходимости множества классов — исключений, потому WTF мне хватает =)
А почему в личку? Оставьте хотя бы в каменнтах. Думаю, многим будет интересно.
github.com/Breathless/Codeine/blob/master/Core/Code/M60.php
Это реализация синглтона.
github.com/Breathless/Codeine/tree/master/Driver/
Это кучка с функциями.
Пиара не хочется, потому что сам по себе движок в альфе, хотя и работает уже на благо некоторых проектов.
Это реализация синглтона.
github.com/Breathless/Codeine/tree/master/Driver/
Это кучка с функциями.
Пиара не хочется, потому что сам по себе движок в альфе, хотя и работает уже на благо некоторых проектов.
В пиаре движка нет ничего плохого.
и чо пеар эта плоха???
Не бойтесь пиара, ссылочку в массы, пожалуйста. (А то ведь задолбают, если каждому в личку)
Разнесением на классы в PHP пытаются скомпенсировать отсутствие понятия модульности и пространства имен.
Пространства имён, уже есть.
Под модульностью можно понимать много чего.
Я думаю, всё таки разнесением на классы в PHP пытаются добиться ООП =)
Под модульностью можно понимать много чего.
Я думаю, всё таки разнесением на классы в PHP пытаются добиться ООП =)
> Пространства имён, уже есть.
«Ну и кому они нафиг нужны?!» © Ави из Snatch :)
В смысле: уже прекрасно научились обходиться без них. Иногда их не используют сознательно поскольку остается еще много неадминистрируемых серверов со старым php < 5.3.0.
> Интерфейс Hash, класс Abstract_Hash, потомок Hash_MD5…
Эта библиотека скорей всего относится к неподдерживаемому более коду. Кстати, покуда работал с множеством функций cryptohash мне тоже нравилось адресоваться к ним с использованием фасетного метода классификации. Но предлагаемая схема не подойдет в качестве универсального приема для любого функционала, даже для того же шаблона Strategy.
В чем действительно безоговорочно согласен, что удобство ООП ярче выражено там, где оно само напрашивается: добавляя к документированному коду интуитивность восприятия.
«Ну и кому они нафиг нужны?!» © Ави из Snatch :)
В смысле: уже прекрасно научились обходиться без них. Иногда их не используют сознательно поскольку остается еще много неадминистрируемых серверов со старым php < 5.3.0.
> Интерфейс Hash, класс Abstract_Hash, потомок Hash_MD5…
Эта библиотека скорей всего относится к неподдерживаемому более коду. Кстати, покуда работал с множеством функций cryptohash мне тоже нравилось адресоваться к ним с использованием фасетного метода классификации. Но предлагаемая схема не подойдет в качестве универсального приема для любого функционала, даже для того же шаблона Strategy.
В чем действительно безоговорочно согласен, что удобство ООП ярче выражено там, где оно само напрашивается: добавляя к документированному коду интуитивность восприятия.
Нифига себе пятничный топик :)
ЗЫ. Наверное память хорошо тренируется с таким подходом — ведь можно забыть про autocomplete в IDE.
ЗЫ. Наверное память хорошо тренируется с таким подходом — ведь можно забыть про autocomplete в IDE.
Пока в одиночку пишешь наверное можно так делать, хотя считаю это извращениями и не совсем красивым подходом.
Но когда проект начнёт разрастаться и шириться на людей будет сложно повлиять, начнут забывать, изобретать очередной велосипед, каждый начнёт своё добавлять и т.п. В общем каша получится и это испортит настроение в коллективе :)
Но когда проект начнёт разрастаться и шириться на людей будет сложно повлиять, начнут забывать, изобретать очередной велосипед, каждый начнёт своё добавлять и т.п. В общем каша получится и это испортит настроение в коллективе :)
К слову, нет ничего плохого в велосипедах, в этом случае — хочешь писать свою реализацию — пиши, это не затронет другой код.
Не хочешь, используй существующую.
Не хочешь, используй существующую.
Раз пять открывал гитхаб твой c июня и всегда не хватало терпения дзен постичь, а тут вот и статья подоспела)
Которая, впрочем, объектную парадигму в моей голову не обрушила.
Зато заставила невольно вспомнить плюсы IntelliSense: «… Она ускоряет разработку ПО, уменьшая количество имён и параметров, которые программист должен держать в памяти. Кроме того, она уменьшает количество необходимых запросов к документации, выводя часть документации в виде всплывающих окон в редакторе кода.»
Оригинальный велик, как и сам создатель. Жги!
Которая, впрочем, объектную парадигму в моей голову не обрушила.
Зато заставила невольно вспомнить плюсы IntelliSense: «… Она ускоряет разработку ПО, уменьшая количество имён и параметров, которые программист должен держать в памяти. Кроме того, она уменьшает количество необходимых запросов к документации, выводя часть документации в виде всплывающих окон в редакторе кода.»
Оригинальный велик, как и сам создатель. Жги!
Напомнило ogl
void glVertex2sv( const GLshort * v);
void glVertex2iv( const GLint * v);
void glVertex2fv( const GLfloat * v);
void glVertex2dv( const GLdouble * v);
void glVertex3sv( const GLshort * v);
void glVertex3iv( const GLint * v);
void glVertex3fv( const GLfloat * v);
void glVertex3dv( const GLdouble * v);
void glVertex4sv( const GLshort * v);
void glVertex4iv( const GLint * v);
void glVertex4fv( const GLfloat * v);
void glVertex4dv( const GLdouble * v);
v
Specifies a pointer to an array of two, three, or four elements. The elements of a two-element array are x and y; of a three-element array, x, y, and z; and of a four-element array, x, y, z, and w.
Очередной быдло-похапе-разработчик… Почитайте хотя бы про современные тенденции программирования, которые (неужели?!) начали потихоньку проникать и в мир PHP. Про тот же самый IoC.
Если вам не хватает AOP или иных, опять-таки современных, фич многих языков, то пора, наконец, осознать, что PHP — не единственный язык и дааааааалеко не лучший. Даже для web разработки.
Не надо требовать от языка того, на что он не способен. Не надо писать код с дикими извращениями вместо смены языка.
Проект надо обязательно писать на PHP и без AOP (к примеру) обойтись очень трудно? Либо поставьте модуль к PHP (а такие есть) и хоститесь как минимум на VDS, либо делайте сборщик вашего проекта с парсером исходных кодов и используйте все прелести подхода continuous integration.
ЗЫ: Как может тимлид (инфа из вашего профиля) не осознавать насколько может повысить скорость разработки хороший редактор и использование его фич — лично для меня загадка. PHPDoc, autocomplete и т.п. Понимаю, настоящие PHP разработчики пишут только в блокноте, но, бля, попробовать-то хотя бы стоило!
Если вам не хватает AOP или иных, опять-таки современных, фич многих языков, то пора, наконец, осознать, что PHP — не единственный язык и дааааааалеко не лучший. Даже для web разработки.
Не надо требовать от языка того, на что он не способен. Не надо писать код с дикими извращениями вместо смены языка.
Проект надо обязательно писать на PHP и без AOP (к примеру) обойтись очень трудно? Либо поставьте модуль к PHP (а такие есть) и хоститесь как минимум на VDS, либо делайте сборщик вашего проекта с парсером исходных кодов и используйте все прелести подхода continuous integration.
ЗЫ: Как может тимлид (инфа из вашего профиля) не осознавать насколько может повысить скорость разработки хороший редактор и использование его фич — лично для меня загадка. PHPDoc, autocomplete и т.п. Понимаю, настоящие PHP разработчики пишут только в блокноте, но, бля, попробовать-то хотя бы стоило!
С меня в очередной раз сорвали все покровы, бида-бида =)
Я знаю что такое IoC, и про тенденции тоже. И про CI.
Но я люблю PHP. Я не хочу уходить с него. Да и куда?
Остальное комментировать, не имеет смысла, судя по (инфе из вашего профиля).
PS: Тимлид пользует нетбинсом, в котором видит дерево проекта, и знает, где у него что лежит.
Перед тем, кидаться словами вроде быдло, вы бы подумали.
Может быть, быдло это те, кто без автокомплита как слепые котята?
Я знаю что такое IoC, и про тенденции тоже. И про CI.
Но я люблю PHP. Я не хочу уходить с него. Да и куда?
Остальное комментировать, не имеет смысла, судя по (инфе из вашего профиля).
PS: Тимлид пользует нетбинсом, в котором видит дерево проекта, и знает, где у него что лежит.
Перед тем, кидаться словами вроде быдло, вы бы подумали.
Может быть, быдло это те, кто без автокомплита как слепые котята?
> Да и куда?
Хаскел. Разве нет?
Хаскел. Разве нет?
Конечно «да и куда» — вопрос совсем холиварный :)
Но все-таки рискну предложить все-таки более серьезно присмотреться на node.js
Если сравнить с PHP, то по синтаксису особо и учить ничего не надо. А как раз Вашу отношение к ООП и любовь к функциям тут можно применить с большим эффектом.
P.S. Сам уважаю PHP, и ни в коем случае не хотел бы говорить, что javascript лучше PHP. Просто Ваш подход использования функций очень уж напомнил то, что есть в некоторых библиотеках для node.js (особенно, выполняющих функцию routing'а).
Но все-таки рискну предложить все-таки более серьезно присмотреться на node.js
Если сравнить с PHP, то по синтаксису особо и учить ничего не надо. А как раз Вашу отношение к ООП и любовь к функциям тут можно применить с большим эффектом.
P.S. Сам уважаю PHP, и ни в коем случае не хотел бы говорить, что javascript лучше PHP. Просто Ваш подход использования функций очень уж напомнил то, что есть в некоторых библиотеках для node.js (особенно, выполняющих функцию routing'а).
Остальное комментировать, не имеет смысла, судя по (инфе из вашего профиля).
Если Вы о карме и рейтинге, то это еще не значит ничего. Посмотрите его комментарии — ему неинтересна собственная карма/рейтинг, он отстаивает свое мнение. Это вовсе не троллинг.
Отстаивать мнение можно и с битой в подворотне.
А можно, и без хамства.
А можно, и без хамства.
ути какая неженка *о*
После прочтения резюме на вашем сайте по поводу «быдло-разработчика» беру свои слова назад.
Как мне кажется, сильный разработчик при написании такого топика начал бы его в стиле: «т.к. мне сильно не хватало таких-то фич, тут у меня появилось набор идей, но поскольку я предпочитаю доводить дела до конца, то свои идеи я оформил в следующий фреймворк и даже опробовал его на паре мелких проектах. приглашаю людей к обсуждению». На данный момент ваш текст скорее близок к «40 способам ускорить PHP».
В том, что вы выложили, я вижу попытку изобрести свою альтернативу IoC и AOP (это я про фичу с ACL, хотя тут не обязательно именно AOP). Зачем? Есть привычные всем термины и реализации. Если уж изобретаете альтернативу, то она должна быть значительно лучше, чтобы не просто оправдывать свое использование, но и оправдывать затраты на обучение. Но лично мне, дураку, совершенно не видится плюсов вашего решения в сравнении с названными паттернами. А вот минусов видится много.
И, да, в команде должен быть человек, способный сказать своему начальнику «ты мудак». В противном случае у вас слабая команда.
Поскольку пишу раз в час, то отвечу в этом комментарии на все.
> Но я люблю PHP. Я не хочу уходить с него. Да и куда?
Прекрасно, но зачем превращать PHP непонятно во что?
Я сейчас пишу одновременно и на PHP, и на Java. Для меня, как программиста, преимущества жавы очевидны. Но также для меня, как не полного идиота, очевидно, что помимо моих чисто программистких симпатий существуют рынок труда, стоимость освоения технологии, кол-во известных заказчику CMS (привет ненавистному мною Битриксу, который так легко продается благодаря бренду 1С) и т.п.
> Может быть, быдло это те, кто без автокомплита как слепые котята?
Вот есть у меня класс с названием в ~10 символов и в нем константа еще в ~20 символов. При написании кода в блокноте я должен держать еще одну табу с этим классов, чтобы быстро копи-пастить. А теперь представим, что надо писать высокоуровневую логику, где задействовано много классов. Вы их все вплоть до символа помните? В Eclipse же набираю первые символы класса, жму enter, выбираю константу и списков члена класса и снова жму enter. При этом PHPDoc помогает мне совершать меньше ошибок несоответствия типов.
> имхо человек просто ищет свой путь, вот ему в данный момент понравилось поработать с таким решением, пройдёт время он найдет другие пути и постигнет свой дзен (ну или не постигнет)
Как написано выше, об этом надо было бы сказать в начале. И не предлагать это как фреймворк к разработке, обосновывая тем, что он уже опробован на паре проектах.
> Что это за современные тенденции программирования — все усложнять
Есть такое. Сильно проявляется в мире Java. И это есть плохо. Для простенького сайта с несколькими сервлетами подключать огромный фреймворк типа Spring — идиотизм. Очень часто это не оправданно. Ровно тоже самое относится и к PHP.
> Если AOP и IOC не являются простыми и очевидными в каком-то языке, то это уже проблема языка, что нужны костыли для реализации простых идей.
Проблема языка, да. Но зачем костыли? Альтернатив много, вместо написания костылей, лучше развивать гибкость мозга, чтобы работать с тем что есть. Регулярно встречаются библиотеки для реализации «классов» на JS. Нахрена?
PHP- такой, какой есть. Хреново спроектированный, с кучей быдло-кодеров, с абсолютно большинством фич спертых из других языков с опозданием лет в 5, как минимум. Это надо либо принять, либо сменить язык. Совершенно не представляю как можно находиться посередине и чувствовать себя комфортно.
Как мне кажется, сильный разработчик при написании такого топика начал бы его в стиле: «т.к. мне сильно не хватало таких-то фич, тут у меня появилось набор идей, но поскольку я предпочитаю доводить дела до конца, то свои идеи я оформил в следующий фреймворк и даже опробовал его на паре мелких проектах. приглашаю людей к обсуждению». На данный момент ваш текст скорее близок к «40 способам ускорить PHP».
В том, что вы выложили, я вижу попытку изобрести свою альтернативу IoC и AOP (это я про фичу с ACL, хотя тут не обязательно именно AOP). Зачем? Есть привычные всем термины и реализации. Если уж изобретаете альтернативу, то она должна быть значительно лучше, чтобы не просто оправдывать свое использование, но и оправдывать затраты на обучение. Но лично мне, дураку, совершенно не видится плюсов вашего решения в сравнении с названными паттернами. А вот минусов видится много.
И, да, в команде должен быть человек, способный сказать своему начальнику «ты мудак». В противном случае у вас слабая команда.
Поскольку пишу раз в час, то отвечу в этом комментарии на все.
> Но я люблю PHP. Я не хочу уходить с него. Да и куда?
Прекрасно, но зачем превращать PHP непонятно во что?
Я сейчас пишу одновременно и на PHP, и на Java. Для меня, как программиста, преимущества жавы очевидны. Но также для меня, как не полного идиота, очевидно, что помимо моих чисто программистких симпатий существуют рынок труда, стоимость освоения технологии, кол-во известных заказчику CMS (привет ненавистному мною Битриксу, который так легко продается благодаря бренду 1С) и т.п.
> Может быть, быдло это те, кто без автокомплита как слепые котята?
Вот есть у меня класс с названием в ~10 символов и в нем константа еще в ~20 символов. При написании кода в блокноте я должен держать еще одну табу с этим классов, чтобы быстро копи-пастить. А теперь представим, что надо писать высокоуровневую логику, где задействовано много классов. Вы их все вплоть до символа помните? В Eclipse же набираю первые символы класса, жму enter, выбираю константу и списков члена класса и снова жму enter. При этом PHPDoc помогает мне совершать меньше ошибок несоответствия типов.
> имхо человек просто ищет свой путь, вот ему в данный момент понравилось поработать с таким решением, пройдёт время он найдет другие пути и постигнет свой дзен (ну или не постигнет)
Как написано выше, об этом надо было бы сказать в начале. И не предлагать это как фреймворк к разработке, обосновывая тем, что он уже опробован на паре проектах.
> Что это за современные тенденции программирования — все усложнять
Есть такое. Сильно проявляется в мире Java. И это есть плохо. Для простенького сайта с несколькими сервлетами подключать огромный фреймворк типа Spring — идиотизм. Очень часто это не оправданно. Ровно тоже самое относится и к PHP.
> Если AOP и IOC не являются простыми и очевидными в каком-то языке, то это уже проблема языка, что нужны костыли для реализации простых идей.
Проблема языка, да. Но зачем костыли? Альтернатив много, вместо написания костылей, лучше развивать гибкость мозга, чтобы работать с тем что есть. Регулярно встречаются библиотеки для реализации «классов» на JS. Нахрена?
PHP- такой, какой есть. Хреново спроектированный, с кучей быдло-кодеров, с абсолютно большинством фич спертых из других языков с опозданием лет в 5, как минимум. Это надо либо принять, либо сменить язык. Совершенно не представляю как можно находиться посередине и чувствовать себя комфортно.
Во-первых, пост не про конкретный код. И не про конкретный фреймворк.
Во-вторых, я не спорю, что можно сменить язык, и быть счастливым.
Но пока что PHP выгоден, и мне проще (да и придётся), двигать его, теми или иным велосипедами, к удобству.
Потому что двигать кучу джуниоров к питону и руби сложнее, да и не нужно.
Техпроцесс уже слаженный.
В-третьих, плюсы, минусы были указаны в топике. И я не считаю, что альтернатива всегда должна быть сокрушительна хороша. Она просто другая.
В-четвёртых, у меня есть кодер, который регулярно мне говорит, что я мудак, в образовательных целях =)
В-пятых, да, PHP хреново спроектирован. Но пост про него, а не про то, как всем надо перейти на нормальный язык.
В-шестых, по поводу усложнений, тут можно поспорить, что именно усложняет больше — ООП, или «АОП на коленке».
Во-вторых, я не спорю, что можно сменить язык, и быть счастливым.
Но пока что PHP выгоден, и мне проще (да и придётся), двигать его, теми или иным велосипедами, к удобству.
Потому что двигать кучу джуниоров к питону и руби сложнее, да и не нужно.
Техпроцесс уже слаженный.
В-третьих, плюсы, минусы были указаны в топике. И я не считаю, что альтернатива всегда должна быть сокрушительна хороша. Она просто другая.
В-четвёртых, у меня есть кодер, который регулярно мне говорит, что я мудак, в образовательных целях =)
В-пятых, да, PHP хреново спроектирован. Но пост про него, а не про то, как всем надо перейти на нормальный язык.
В-шестых, по поводу усложнений, тут можно поспорить, что именно усложняет больше — ООП, или «АОП на коленке».
Знаете что меня удивляет? Вот вы работаете тимлидом. Вместо того, чтобы вводить стандартные (в понимании многих других разрабов) вещи, которые помогут ускорить обучение, вливание в команду нового работника, вы пишите свой велосипед, который имеет серьезные минусы в плане возможностей документирования.
Было бы вас 1-2 стартапера-партнера — без проблем. Но ведь вам с подчиненными работать надо.
Конечно, «если все используют, то и мы должны» — не аргумент. Но область его применения, точнее его опровержения, не бесконечна. Должны же быть некие стандарты в корпоративной разработке.
Что я хочу сказать? На каждом углу сейчас пропагандируется ООП. Джуниоры с этого обычно и начинают. Да, используется ООП с надобностью и пониманием и без. Если у вас маленькая, слаженная и сильная команда, то можно придумывать что угодно, но если у вас есть хоть небольшая текучка кадров, то....?
Если меня подчиненный спрашивает как сделать что-то, то я расскажу ему о наиболее близком для него решению. И дам ссылок на статьи, где это описывает кто-то помимо меня, т.к. у меня могу быть проблемы с выражением мыслей.
Если в работе так и напрашивается паттерн IoC, то рассказывать я буду именно о нем. Расскажу в общем, потом дам ссылку на доку по Symphony и, возможно, покажу примеры в других языках, откуда это и пришло. Но писать собственный велосипед, по сути делающий тоже самое, лично мне бы в голову не пришло.
Было бы вас 1-2 стартапера-партнера — без проблем. Но ведь вам с подчиненными работать надо.
Конечно, «если все используют, то и мы должны» — не аргумент. Но область его применения, точнее его опровержения, не бесконечна. Должны же быть некие стандарты в корпоративной разработке.
Что я хочу сказать? На каждом углу сейчас пропагандируется ООП. Джуниоры с этого обычно и начинают. Да, используется ООП с надобностью и пониманием и без. Если у вас маленькая, слаженная и сильная команда, то можно придумывать что угодно, но если у вас есть хоть небольшая текучка кадров, то....?
Если меня подчиненный спрашивает как сделать что-то, то я расскажу ему о наиболее близком для него решению. И дам ссылок на статьи, где это описывает кто-то помимо меня, т.к. у меня могу быть проблемы с выражением мыслей.
Если в работе так и напрашивается паттерн IoC, то рассказывать я буду именно о нем. Расскажу в общем, потом дам ссылку на доку по Symphony и, возможно, покажу примеры в других языках, откуда это и пришло. Но писать собственный велосипед, по сути делающий тоже самое, лично мне бы в голову не пришло.
имхо человек просто ищет свой путь, вот ему в данный момент понравилось поработать с таким решением, пройдёт время он найдет другие пути и постигнет свой дзен (ну или не постигнет)
О!
После криков «Perl мертв!» дошла очередь и до PHP :)
Даешь С#!
После криков «Perl мертв!» дошла очередь и до PHP :)
Даешь С#!
Что это за современные тенденции программирования — все усложнять. Назвали умными словами простые вещи. Если AOP и IOC не являются простыми и очевидными в каком-то языке, то это уже проблема языка, что нужны костыли для реализации простых идей.
В python, например, никто не слышал ни об AOP, ни об IOC, т.к. для реализации того, что эти слова обозначают, не нужны никакие дикие умные сторонние библиотеки или особые умственные усилия — несложные динамические и ФП-возможности python'а делают как AOP, так и IOC тривиальным и естественными. Это, безусловно, полезные вещи, и гораздо удобнее, когда они «встроены» в язык, а не навешиваются потом абстракциями и костылями.
А когда в php тащат такие вещи, то тащат их туда из Java — обязательно какую-нибудь библиотеку нужно и тд., ну и преподносится это как дар высшего разума низшему.
Причем тут VDS и CI — вообще не понял, если честно)
Но про смену языка — согласен, только, наверное, не в ту сторону) Изначальная аргументация автора — выкинуть ООП и делать проще — очень питонья, и мне кажется, что после перехода на питон автору должно стать комфортно и спокойно. Там не нужно писать классы и держать что-то особенное в голове, чтобы реализовать паттерны Iterator, Observer, Strategy, Factory Method, Abstract Factory, IoC и многие-многие другие: если писать простой и «питоний» код, то все плюшки будут получены почти сами собой.
Ага, фанаты питона в треде, уж простите)
В python, например, никто не слышал ни об AOP, ни об IOC, т.к. для реализации того, что эти слова обозначают, не нужны никакие дикие умные сторонние библиотеки или особые умственные усилия — несложные динамические и ФП-возможности python'а делают как AOP, так и IOC тривиальным и естественными. Это, безусловно, полезные вещи, и гораздо удобнее, когда они «встроены» в язык, а не навешиваются потом абстракциями и костылями.
А когда в php тащат такие вещи, то тащат их туда из Java — обязательно какую-нибудь библиотеку нужно и тд., ну и преподносится это как дар высшего разума низшему.
Причем тут VDS и CI — вообще не понял, если честно)
Но про смену языка — согласен, только, наверное, не в ту сторону) Изначальная аргументация автора — выкинуть ООП и делать проще — очень питонья, и мне кажется, что после перехода на питон автору должно стать комфортно и спокойно. Там не нужно писать классы и держать что-то особенное в голове, чтобы реализовать паттерны Iterator, Observer, Strategy, Factory Method, Abstract Factory, IoC и многие-многие другие: если писать простой и «питоний» код, то все плюшки будут получены почти сами собой.
Ага, фанаты питона в треде, уж простите)
В плане читабельности, не лучший.
В плане скорости чистый php зачастую впереди таких языков, как Ruby и Python.
В плане скорости чистый php зачастую впереди таких языков, как Ruby и Python.
1. Без автокомплита чужому человеку будет очень тяжко разбираться в вашем коде
2. Без кодестайла -//-
3. Без PHPDoc -//-
Даже отбросив любовь к ООП, то, если честно, не увидел ничего привлекательного в подобном вызове:
Неужели так хуже?:
И да, любовь к статическим классам надо пресекать, подумайте о тестировании…
2. Без кодестайла -//-
3. Без PHPDoc -//-
Даже отбросив любовь к ООП, то, если честно, не увидел ничего привлекательного в подобном вызове:
Code::E('Security/CAPTCHA', 'Generate', array('Ticket'=>Client::$Ticket));
Неужели так хуже?:
\Security\Captcha\Generate(Client::$Ticket);
И да, любовь к статическим классам надо пресекать, подумайте о тестировании…
Спасибо, за коммент по делу.
В случае с ООП и сильным связыванием, ваш пример будет вообще таким, еще лаконичнее:
\Security\Captcha\Generate();
(ведь мы же знаем, что где Клиент:: Тикет)
Хотя в реальном проекте, сюда подмешается еще идентификация конкретной реализации.
И он не лучше, и не хуже, он просто другой.
Вполне себе читаемо, это раз, во вторых, я кажется указал плюсы и минусы, в том числе читаемость.
Чем мешают статические классы тестированию, не представляю, будет интересно узнать.
В случае с ООП и сильным связыванием, ваш пример будет вообще таким, еще лаконичнее:
\Security\Captcha\Generate();
(ведь мы же знаем, что где Клиент:: Тикет)
Хотя в реальном проекте, сюда подмешается еще идентификация конкретной реализации.
И он не лучше, и не хуже, он просто другой.
Code::E( 'Security/CAPTCHA',
'Generate',
array(
'Ticket' => Client::$Ticket
)
);
Вполне себе читаемо, это раз, во вторых, я кажется указал плюсы и минусы, в том числе читаемость.
Чем мешают статические классы тестированию, не представляю, будет интересно узнать.
Меня заинтересовало то, как Вы это описали, но поковырявшись в исходниках драйверов, ничего не понял.
Можно плз ссылочку в личку на какой-нибудь хеловорд с гостевухой, анимироваными кабанчиками и азартными играми.
Можно плз ссылочку в личку на какой-нибудь хеловорд с гостевухой, анимироваными кабанчиками и азартными играми.
«реюзнем кодца» — лучшая фраза недели! )
Можно чуток критики. Не полностью просмотрел ваш код.
Использования ассоциативного массива в качестве аргумента — дорога в ад. И дело совсем не в автодополнении IDE. Когда сталкиваешься с такими функциями, если они не сидят в подкорке в мозгу, то приходится лезть и смотреть реализацию этой функции. На скорость работы это влияет сильно. Вам это не заметно, так как вы их автор, но другим людям будет очень неудобно.
Вы таким образом не фиксируете интерфейс функций. Это плохой тон. На больших проектах такой подход будет фатален.
Использования ассоциативного массива в качестве аргумента — дорога в ад. И дело совсем не в автодополнении IDE. Когда сталкиваешься с такими функциями, если они не сидят в подкорке в мозгу, то приходится лезть и смотреть реализацию этой функции. На скорость работы это влияет сильно. Вам это не заметно, так как вы их автор, но другим людям будет очень неудобно.
Вы таким образом не фиксируете интерфейс функций. Это плохой тон. На больших проектах такой подход будет фатален.
Вы изобретаете собственный ООП =)
У Вас "/Generate/Entropy/" = базовый абстрактный класс.
«MonteCarlo.php» = конкретная реализация.
Только в ООП сигнатуры методов задаются жестко, а у Вас только в комментариях.
«Code» = ServiceLocator. Вызывает конкретный «драйвер» (реализацию класса) по его «пространству имен» (абстрактному классу). + AOP-процессор. Навешивает на вызовы методов логирование, кеширование и т.д.
У Вас "/Generate/Entropy/" = базовый абстрактный класс.
«MonteCarlo.php» = конкретная реализация.
Только в ООП сигнатуры методов задаются жестко, а у Вас только в комментариях.
«Code» = ServiceLocator. Вызывает конкретный «драйвер» (реализацию класса) по его «пространству имен» (абстрактному классу). + AOP-процессор. Навешивает на вызовы методов логирование, кеширование и т.д.
Может быть, и как раз таки от жесткой фиксации хотелось отойти =)
Но Вы же сами занесли в минуса использование массивов вместо жестких сигнатур.
Да, но не потому что они мягкие, а потому что это дело надо документировать, и можно ошибиться.
Влезу уж опять: попробуйте python)
В суть подхода я, признаюсь, вникать не стал, т.к. считаю, что мотивация важнее. Мне просто показалось, что мотивация/ход мыслей у Вас питоний по сути, и в python все так, как Вы хотите: там за «Интерфейс Hash, класс Abstract_Hash, потомок Hash_MD5» вместо простой функции будут всегда бить по рукам.
Это помимо огромного числа других преимуществ (более простой и удобный язык: например, в функции можно передавать как обычные (по порядку), так и именованные параметры, примерно как Ваше соглашение о передаче массива, только более удобно; бОльшее число хороших библиотек на все случаи жизни — написанных по-питоньи, а не «Abstract_Hash», налаженная система распространения пакетов — не то, что pear; наличие хороших фреймворков, которые не городят абстракции a'la Criteria(...), а упрощают код, и тд).
В суть подхода я, признаюсь, вникать не стал, т.к. считаю, что мотивация важнее. Мне просто показалось, что мотивация/ход мыслей у Вас питоний по сути, и в python все так, как Вы хотите: там за «Интерфейс Hash, класс Abstract_Hash, потомок Hash_MD5» вместо простой функции будут всегда бить по рукам.
Это помимо огромного числа других преимуществ (более простой и удобный язык: например, в функции можно передавать как обычные (по порядку), так и именованные параметры, примерно как Ваше соглашение о передаче массива, только более удобно; бОльшее число хороших библиотек на все случаи жизни — написанных по-питоньи, а не «Abstract_Hash», налаженная система распространения пакетов — не то, что pear; наличие хороших фреймворков, которые не городят абстракции a'la Criteria(...), а упрощают код, и тд).
Жестко или нет заданы сигнатуры функций — это ну никак не связано с ООП.
В основе ООП, ФП и других подходов лежат простые принципы — DRY, KISS. ООП — просто один из способов реализации этих принципов. Смысл тогда объяснять другие подходы в терминах ООП?
Так же точно можно в функциях высшего порядка увидеть реализацию паттерна Стратегия. А можно посмотреть с другой стороны, и увидеть, что паттерн Стратегия, реализованный через классы — это такой недоделанный, неудобный и сложный костыль для языков, которые не поддерживают функции высшего порядка.
Короче говоря, в ООП нет ничего такого, что делало бы его венцом эволюции методов разработки ПО. Это полезный инструмент, но hype по его поводу вроде как остался уже чуть ли не в прошлом тысячелетии.
В основе ООП, ФП и других подходов лежат простые принципы — DRY, KISS. ООП — просто один из способов реализации этих принципов. Смысл тогда объяснять другие подходы в терминах ООП?
Так же точно можно в функциях высшего порядка увидеть реализацию паттерна Стратегия. А можно посмотреть с другой стороны, и увидеть, что паттерн Стратегия, реализованный через классы — это такой недоделанный, неудобный и сложный костыль для языков, которые не поддерживают функции высшего порядка.
Короче говоря, в ООП нет ничего такого, что делало бы его венцом эволюции методов разработки ПО. Это полезный инструмент, но hype по его поводу вроде как остался уже чуть ли не в прошлом тысячелетии.
Подход интересный, но, на мой взгляд, не очень практичный. Особенно, учитывая развитие php в настоящее время.
Мои глаза…
Что такое Overhead?
Ваш подход идеален для простых утилит, которые выполняют элементарное действие и имеют короткое удобное наименование. Например, преобразовать строчное представление массива в массив или отсортировать массив. Системы на таком подходе похудеешь делать.
Ваш подход идеален для простых утилит, которые выполняют элементарное действие и имеют короткое удобное наименование. Например, преобразовать строчное представление массива в массив или отсортировать массив. Системы на таком подходе похудеешь делать.
Глянул ваши исходники. А что мешает класс, не содержащий не статических методов, объявить абстрактным и не писать static через каждый чих?
где примеры использования?
из того что понял — зачем нужен синглтон с методами, если можно использовать функцию со статической переменной?
из того что понял — зачем нужен синглтон с методами, если можно использовать функцию со статической переменной?
Примеры использования чего?
Это не топик, пиарящий движок.
Это рассказ о концепции.
Это не топик, пиарящий движок.
Это рассказ о концепции.
пример, где твой подход полезнее оопшного с фабриками или IoC?
а то плохо понятно что твой код делает.
а то плохо понятно что твой код делает.
Как-то раз, я попробовал прочитать топик, перед тем как комментировать.
И сразу стало скучно жить, спрашивать стало нечего.
Очень рад, что вы не ступили на эту скользкую дорогу, как я.
И сразу стало скучно жить, спрашивать стало нечего.
Очень рад, что вы не ступили на эту скользкую дорогу, как я.
вот не нужно ёрзничать, я читал дважды, смотрел код, да и Вы САМИ в комментах выше писали habrahabr.ru/blogs/php/103465/#comment_3218776
Сорри, нужен именно пример? Будет, позже, записал ваш ник.
Еще раз упомяну: это не поход против ООП. Это просто другой подход, со своими плюсами и минусами.
Еще раз упомяну: это не поход против ООП. Это просто другой подход, со своими плюсами и минусами.
мне почему-то кажется что вы делаете www.php.net/manual/en/function.runkit-function-redefine.php и дальше по списку?
p.s. мне фиолетово насчёт ООП-шности, хочется правильно понять Вашу идею
p.s. мне фиолетово насчёт ООП-шности, хочется правильно понять Вашу идею
распишу пожалуй о своём подходе:
весь движок состоит из модулей. модуль — это пхп файл, который может содержать как непосредственно код, так и определение класса, объекта или функции.
есть модуль «ядро» — он подгружается обычным инклудом, другие модули уже подгружаются через ядро: $core->db_main — подгружает файл db/main.php который возвращает объект доступа к основной базе. а в нём, например, подгружается $core->db_driver_pdo который возвращает класс драйвера. он инстанцируется с параметрами, кешируется и возвращается при обращении к $core->db_main. $core — локальная переменная, которая доступна внутри модуля. о сохранении её в классе модуль заботится сам. имена классов и функций можно делать хоть полной белибердой — доступ к ним осуществляется по пути их расположения. внутри модуля может быть не собственно код, а роутер подключающий другой модуль в зависимости от условий. при этом по имени чётко понятно в каком файле искать код
весь движок состоит из модулей. модуль — это пхп файл, который может содержать как непосредственно код, так и определение класса, объекта или функции.
есть модуль «ядро» — он подгружается обычным инклудом, другие модули уже подгружаются через ядро: $core->db_main — подгружает файл db/main.php который возвращает объект доступа к основной базе. а в нём, например, подгружается $core->db_driver_pdo который возвращает класс драйвера. он инстанцируется с параметрами, кешируется и возвращается при обращении к $core->db_main. $core — локальная переменная, которая доступна внутри модуля. о сохранении её в классе модуль заботится сам. имена классов и функций можно делать хоть полной белибердой — доступ к ним осуществляется по пути их расположения. внутри модуля может быть не собственно код, а роутер подключающий другой модуль в зависимости от условий. при этом по имени чётко понятно в каком файле искать код
function F_MonteCarlo_Random($Args)
{
return mt_rand($Args['Min'], $Args['Max']);
}
Все же префикс mt_ здесь от Mersenne twister ГСЧ.
А «реюзанем кодца» — это, да, шедевр, я щетаю.
Мне кажется вам надо посмотреть на ruby и его monkey patching :)
Не люблю руби, не понимаю истерии по нему.
Когда Твиттер перестанет лежать раз в день, а 37signals станут миллиардерами, я подумаю о переходе =)
Когда Твиттер перестанет лежать раз в день, а 37signals станут миллиардерами, я подумаю о переходе =)
Спасибо вам за статью… теперь я знаю что я не одинок =)
за 6 лет так и не смог понять, зачем всё это монстровидное ООП нужно в php, где в 90% случаев надо сделать 1-3 красивых запроса к базе и отдать это простейшему шаблону за минимальное время
за 6 лет так и не смог понять, зачем всё это монстровидное ООП нужно в php, где в 90% случаев надо сделать 1-3 красивых запроса к базе и отдать это простейшему шаблону за минимальное время
=)
Вообще, у ООП полным полно преимуществ, просто проблема в ООП ради ООП.
Вообще, у ООП полным полно преимуществ, просто проблема в ООП ради ООП.
удобно (особенно всякие готовые классы для мелочевки: авторизация какая нибудь, работа с почтой, твиттером или каким то еще API), но не всегда… за прошлый год поработал на 3х работах, видел много чужого кода — действительно «ООП ради ООП» о_0
самое показательно было в одном проекте: почти 3 мб php кода, только ради 1 запроса к кешу, если нет кеша, то 2-3 запроса к базе + формирование этого самого кеша с шаблонами
задача стояла конкретная, поэтому так и понял зачем было столько всего городить, теперь проект занимает чуть меньше 1 мб (включая JS и основные шаблоны), шустрее работает даже без кеширования, легко переноситься между системами (прошлый так и не завелся в linux) и ООП только в формировании почтового сообщения (какой то чужой удобный класс)
самое показательно было в одном проекте: почти 3 мб php кода, только ради 1 запроса к кешу, если нет кеша, то 2-3 запроса к базе + формирование этого самого кеша с шаблонами
задача стояла конкретная, поэтому так и понял зачем было столько всего городить, теперь проект занимает чуть меньше 1 мб (включая JS и основные шаблоны), шустрее работает даже без кеширования, легко переноситься между системами (прошлый так и не завелся в linux) и ООП только в формировании почтового сообщения (какой то чужой удобный класс)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Функции наносят ответный удар