изначально - это когда он был PHP FI? ну да, был совсем не ооп. а ничего, что его с тех пор переписали почти полностью, несколько раз? )) насчет костылей... и того что ООП в пхп очень дорогое... дорогое по сравнению с чем? с процедурками? или спагетти-кодом? гипотетически конечно дороже, но не настолько чтобы это было поводом от него в пхп отказываться. Можешь подкрепить свои слова хоть чем-то? Сколько пишу на пыхе, большой дороговизны его именно ООП никогда не замечал. он вообще сам дорогой, по памяти и производительности. это да. ну это вообще смешно. пых никогда и не позиционировался как экстремально быстрый. если нужна максимальная производительность то для начала откажись от пхп )) а если собрался писать на пхп - забудь про МАКСИМАЛЬНУЮ производительность. всё просто.
Ну фиг знает. Я за скорость результата и разработки конечно. Но скорость работы тоже важна. И если можно этого добиться без выноса мозга, то и хорошо.
все этого хотят. непонятно только как ооп всему этому мешает. глупый рукожоп напишет выносно-мозговой код и без ООП и с его применением. зло не ООП, а в тех кто не умеет его "готовить".
Категорически не согласен. Мне проще объявить класс, который будет делать возложенные на нее обязанности, и при необходимости редактировать его, не трогая весь процедурный код, и при необходимости создать класс заглушку за место рабочего класса. Так же, можно делать проект на части, легче чем, делить процедурный код. Ну, кто к чему привык. имхо.
ах, не понимает простой люд вашего гения надо больше призрения и ЧСВ... это аксиома. То что вам так проще делать, это не значит что для других код становится понятнее. А он наоборот становится более запутанным из-за введения невных связей и создания новых сущностей.
Тоже поупражняюсь: - ООП ≠ использование ключевых слов типа "class", это скорее использование полезных абстракций. "объектный синтаксис" только добавляет выразительности. да, в php нет некоторых вкусностей в синтаксисе. но если это кого-то парит, наверное он просто слабый проггер. - классы добавляют небольшой оверхед. настолько небольшой, что и х с ним. - непонятны рассуждения о фреймворках "в общем". если фреймворк хорошо decoupled, то можно использовать то, что нравится, оставляя лишний хлам за бортом. с другой стороны, обычно танцуют от готовых сборок или примеров приложений. тут всё грустно. сравни: symfony vs. symfony sandbox или его производные. кто в теме, тот поймёт!
вымараживает новая мода пихать его везде, например в класс создания документов разных форматов пихают DI вместо обычного локатора. Причем пихают прямо конструктор.
Понимаешь, есть хорошие академические фреймворки, которые дают и поддерживаемый код и даже чему-то учат. Есть битриксы, где пофиг на код, зато отличный маркетинг, комьюнити, поддержка и т.п. Есть вордпрес, который бесплатный, популярный и куча людей пользуется и развивает его, который с багажом легаси кода, но старается изменится. А есть какой-то суслик с каким-то "моим проектом", на который... 99.(9)% программистов насрать так глубоко, что можешь хоть с goto писать. Это во-первых. Во-вторых, вопрос бы с недостатках. Вот спрашиваешь конкретные недостатки, а в ответ получаешь чувака, который офигивает от того, как он научился слова складывать в предложения и всем хочет это показать, а заодно помахать своим причиндалом - "смотрите, какой он у меня". Короткий, короткий. Нервное? К врачу обратись. Добавлено спустя 1 минуту 55 секунд: Да нет, это когда у троля зудит в заднице, он ищет - на что бы насрать. Есть толстые троли, есть тонкие. А есть тупые. Первые два типа понимают, что они тролят, а последний - просто даже в тему не вдается - он способен вычленить знакомые ключевые слова в чужом посте и прибежать гыгыкать. Добавлено спустя 3 минуты 29 секунд: DI и есть пихание зависимостей в класс. В идеале - через конструктор. Это офигенно удобно, ибо твой класс сразу видно - от чего зависит. С локатором сложнее - ты его таскаешь везде, в нем куча всего и понять - что же нужно этому классу - становится значительно сложнее. Ясно дело, что эти преимущества выливаются или при переносе классов в другой проект или при юнит-тестировании. Другое дело, что чистый DI в больших проектах сложно управляется, по-этому и появляются всякие DI контейнеры, конфиги зависимостей и т.п.
Нет, всего-лишь сарказм основанный на опыте. То, что называют ООП - это далеко не то, что ООП значит по определению ) Ну вот так. Когда в программировании идет речь про ООП - речь идет не "давайте передем на объекты", а говорят о соблюдении набора принципов. Тот же SOLID, хотя бы. К слову, часть принципов и без ООП работает. А построить нужную схему классов с соблюдением этих принципов - тут правда нужны и знания и опыт. А часто бывает, что наговнокодят так, что процедурники содрогаются и зовут это ООП И второе - ООП направлен на удешевление поддержки. Что бы проще было проект развивать, разбираться с ним другим людям (а ротация кадров есть всегда), что бы исправляя код в одном месте у вас не отваливалось в других. Вот те три фразы и выходят из сказанного. И совсем никакого чсв, это реальность. Добавлено спустя 4 минуты 19 секунд: Да не, это недолго. Ща придет суслик покидает говна и в общем все, тема закрыта
Удобно. Я у себя тоже где надо DI использую Проблема в том что его пихают просто везде, потому что модно. Тоесть в тех местах где его преимущества понадобятся с вероятностью 0.1%. Да ещё и с конфигами. короче мой посыл был такой, что ООП ради ООП - это хуже чем говнопроцедурник. т.к. я то правками занимаюсь, скажу что разбираться в ООП тем сложнее, чем больше абстракций и сущностей. Вот и получается что выбешивают тонны классов в один метод, методов в одно строчку и т.п.
Хз. Я крайне редко прихожу к ситуации, когда требуется создание экземпляров, и уж тем более наследование.
Ты мой пост выше вообще не читал, да? Ок. Где там написано про отказ? Или максимализм мешает осознать, что ООП или не-ООП это не вопрос выбора, религии и жизненого пути, а просто, внезапно, выбор инструментария, уместного или нет в том месте, где планируется его применять? Мысли уже по-взрослому. Ок, перефразирую. Максимально возможную из того, что может дать текущая среда разработки. Он слишком опытен и великогениален, чтобы это принять. Я сказал все, что счел нужным. Ответил на вопросы касательно своего отношения к ООП в пхп. Привел примеры из жизни. Если тебя это чем-то раздражает, или встретил непонятные семантические конструкции, вызывающие жжение в причинном месте, это сугубо.твои.проблемы. Твой же ответ можно свести к одному предложению: "азаза, все равно я Д'Артаньян, ой все". Огромная полезная информационная нагрузка, учитывая, что всем плевать на твое самолюбие, почесывание которого составляет больше половины всей прозводимой тобою тут информации. Ты даже тут избыточен. Налетайте, посоны, я с собой захватил:
Конфиги как раз очень часто нужно подменять. Как минимум для тех же тестов, дев/продакшн версия. Если в приложении действующий DI контейнер, то зачем создавать еще сервис локатор - это уже избыток. Если ты умеешь и зднаешь как едят DI - то никаких проблем его таскать. Хуже он точно не сделает. Не, для простых проектов можно и SL обойтись, особо если других механизмов нет, но и проблем использовать DI сразу тоже не вижу. Я просто не знаю что такое ООП ради ООП. Это такой лозунг, который никто толком не понимает что значит. Оверинжениринг? Но это не проблема ООП, и в процедурном стиле можно такое накрутить, что ой. Другое дело, когда пишут "в ООП" люди, которые заявляют, что мол "интерфейсы я не использую, они в моих проектах не нужны". Ну тут понятно, что может случится. Разбираться в C# сложнее, чем в PHP. Разбираться в Ван Гоге сложнее, чем в Рубенсе. Да ну, странная фраза какая-то. А мне вот сложно было разбиратся в вордпресс. Ибо вместо того, что бы взять сущность поста, посмотреть интерфейс и понять - что можно делать, - нужно вместо этого вызвать магическую последовательность функций, о которой нужно узнать лишь разбираясь в исходном коде. Вот практическая разница. Добавлено спустя 4 минуты 12 секунд: Ты сказал кучу общих фраз, но не дал ни одного конкретного ответа на вопрос - в чем именно недостатки ООП. Ну за исключением какой-то хрен знает как и кем переписанной джумлы, которая вдруг стала есть 12м памяти. Угу, а джып, внезапно, жрет больше бензина, чем мопед, и чо? Так что или давай конкретные и разобранные ответы, или жри свой попкорн, животное. Если говоришь о производительности - то давай оценочные цифры. В обычном приложении (а не hello world), активно юзающем базу и все такое - какая потеря производительности будет?
Что ты дурака включаешь? Что такое Вордпресс, сообщество его разработчиков и развитие, мы понимаем, а что такое Джумла, сообщество ее разработчиков и развитие, мы не понимаем? Я сделаю проще. Я не буду ничего доказывать тому, кто ничего не хочет(не может?) слушать, и заведомо смотрит на всех как на говно. Это безблагодатное занятие. Если тебе так нужно, ТЫ опровергни выдвинутый тезис. Хотя, если ты действительно пишешь такие конструкции и видишь в них полиморфизм: Хотя на деле это перепетое на индусском языке: Код (Text): $foo = function () {...}; $bar = function () {...}; $functions = array($foo, $bar); foreach($functions as $function){ $function(); } То, едва ли у тебя получатся адекватные замеры.
Как быстро суслик обосрался, никакого фана =( (не, обычно так не выражаюсь, но в данном случае специально на его уровень спустился) Добавлено спустя 10 минут 54 секунды: Зы, пример, к слову, не самый удачный был, но кто же знал, что вокруг троль бегает - принюхивается. И от того, что суслик выкинул часть кода и назвал это "менее индусским", он удачнее не стал. Угу, более китайским стал https://www.google.ru/search?q=китайская+флешка Вот так поудачнее будет Код (Text): function render_circle($center, $size) { ... }; function render_box($center, $size) { ... }; function get_render($type) { switch $type { case 'cirlcle': return 'render_circle'; case 'box': return 'render_box'; ... } } call_user_func(get_render('circle'), 10, 10); Тут и полиморфизм и даже вариант простой фабрики. Но опять же, это пример, а не реальный код.