Форум PHP

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

Простой пример:
Допустим, вы используете PDO напрямую.
И тут заказчик говорит: Хочу следить за всеми и видеть лог всего, что добавляется в базу!
И что вы будете делать?

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

Если же вы сразу используете MyDataBaseVeryCoolClass, то вам придется всего лишь поправить его метод MyDataBaseVeryCollQuery. Либо унаследовать от MyDataBaseVeryCoolClass еще какой-нибудь, например MyDataBaseVeryCoolClassWithLogging и опять же переопределить в нем один метод MyDataBaseVeryCollQuery. Но изменение тут же повлияет на весь проект.

Это одна из причин, навскидку.

Ну альтернативы в этой среде применения PHP, вот так что бы полностью заменить чем то все равно нет )

Не спорю, мне даже очень понравилось про табуретки, прямо в точку ... Но так и я не спорю с этим, все это нужно и необходимо, но в необходимом месте и в необходимом количестве. Я писал, что имеет место безудержное увлечение и применение ООП даже там где его применение вовсе не нужно, где проще как в коде так и в немаловажном факторе нагрузки на сервер сценария. Ведь производительность ООП по определению ниже процедурного стиля. В одном случае используя процедурный стиль мы просто умножим $a на $b и получим $c, в случае ООП мы создадим для этого класс, функцию, которая нам посчитает тот же самый результат, но мы уже станем крутыми прогерами используя ООП!
Это конечно тоже как бы все примитивное мое понимание, но по нормальному программист должен думать, должен понимать суть сценария, что он хочет получить и какими методами. И должен выбрать это будет процедурный стиль или объектно-ориентированный а возможно ему нужно сочитать оба стиля для получения оптимального сценария с минимумом байтов и строк скрипта, с минимум подключаемых классов и функций.
Но нужно думать а вот многие берут какие то готовые классы, cms, движки, шаблоны и чаще всего из всех этих наборов библиотек используют только какую то одну-две функции, часто и не знают о наличии и назначении остальных в библиотеках. В итоге для элементарного уравнения умножить (образно говоря) у нас скрипт вырастает до чудовищных размеров а все эти инклуды нам вешают сервер. ООП имеет смысл если нет подобных функций в самом PHP и более того действительно когда у нас эта функция, сценарий на конвейере и вызывается не однократно, в таком случае имеет смысл что бы не прописывать этот сценарий по несколько раз процедурно создать функцию, класс, метод, способ ... который будет вызываться по необходимости.
Ну вот как то так ... Это мое понимание.
Пример вот недавно решил перейти с mysql на pdo, как то он мне более интересен, прост, достаточен чем mysqli. Но это другая тема. В процессе я порыл в сети и нашел несколько классов по работе с PDO. Многие тут же хватаются, вставляют эти классы в свои скрипты и бьют себя в грудь всем рассказывая что ООП это крутяк и я использую ООП и я крутой программист а ты вот процедурный стиль и ты лох! Ну я тут не стал так категоричен и стал изучать этот класс, не буду его называть и ссылки и автора давать. Внутри этого класса оказалось что автор просто тупо продублировал стандартные функции PDO, по сути PDO уже сам по себе является библиотекой, классом и и вместо использования $PDO->query("SELECT * FROM `table`"); я должен этот класс pdo вложить например в MyDataBaseVeryCoolClass->MyDataBaseVeryCollQuery("SELECT * FROM `table`"); И в чем логика? Зачем нужно еще создавать свой класс? Что такое вот делает этот класс, что не может выполнить PDO? И это только один пример а их тысячи в сети. И зачастую что бы сделать простые и элементарные сценарии используя готовые уже функции PHP и его расширений мы ставим Зенд или Смарти или еще что то, что бы умножить 2х2 ... Но при этом сказать что я крутой программист, я не думаю, я не использую процедурный стиль, потому что мне не хватает мозгов подумать, все ведь и так придумали до меня ...

. не так прочитал сначала

Ну есть вопросы к ООП в PHP... ООП это здорово и классно, ООП - это возможность создания очень надежных тестов, которые покрывают приложение почти полностью, ООП - это возможность создавать собственные языки в рамках предметной области... но вы хотя бы перегрузку основных операторов введите... не уж так сложно (учитывая, что она уже есть в базовом C++)? Не нужно забубенных собственных операторов с возможностью настройки приоритета слева и справа, не нужно перегрузок <===> и :?, но хотя бы =, +, - и << можно перегрузить? Вместо нового языка в рамках предметной области на PHP получаются простыни кода...
Пространство имен ввели лишь в PHP 5.3, в результате половина FrameWork-ов состоит из классов с умопомрачительными названиями... Я разрабатывал большие проекты, как на PHP, так и на других языках, и могу с полной уверенностью сказать, что ООП в PHP реализован из рук вон плохо. Хорошо и не могло получится, так как язык не спроектирован как объектно-ориентированный и ООП насажен сверху, насажен плохо, не до конца и не удобно. До изящества ООП в других средах тут далеко. Кое-что делать можно, но это не полноценный ООП, не получается при помощи этого ООП создавать изящные и новые языки в рамках предметной области.

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

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

Это самый примитив.

Честно сказать даже не стал читать всю эту тему, может быть как следсвие мой пост будет офтоп или флуд, но может быть он станет поезным кому то
Откуда взялось в PHP - ООП? Как мое мнение так из ущербных борланд-программистов которых учили в техникумах, колледжах и всяких там академиях и университетах ... Чему их там учили - вот есть пригодная среда программирования ака Борланд, где ты можешь добавить в программу кнопочку и написать в ее свойства, что она выполняет. Отсюда и возникло наше ОБЪЕКТ-ОРИЕНТИРОВАНИЕ, есть кнопка и есть действие выполняемое после ее нажатия, есть объект и есть ориентировка на него в "органах", шучу ... Короче мы как бы имеем массив данных с которым работали ака а = 1, б = 2 и т.п. и нажав кнопку мы передаем этот массив куда то ... As know? А вам известно куда? А не стоит беспокоится убеждает вас ООП все ваши данные, весь ваш обжект передает нам - ОБРАБОТЧИКУ! А кто ты есть? Кто ты такой? Я вас не звал и не просил, откуда вы взялись? Ну как же, я есть обработчик всех ваших данных и при этом выводчик всех ваших результатов. Например ввели вы 2+3 а я вам вот вам результат = 5, сила! Это вам не какие то там процедурные стили, это вам ООП! Ввели вы в обработчик 2 +3 а ось вам и результат = 5, а что при этом сам PHP не считает 2+3=5? Окстись еретик! Ты блин нарушаешь правила и законы ООП! Все должно происходить через "ОБРАБОТЧИК", все! даже 2+3 должно пройти через этот самый обработчик ООП! А зачем он нужен в PHP? Он нужен когда есть какое то нестандартное действие, просто сумма двух чисел в PHP является стандартной, например $a+$b=$c; и здесь нам ООП вовсе не нужен а даже вреден со всеми своими надстройками и нагромождениями пользовательскими функциями. Нам нужен ООП когда у нас имеет место функция $a+$b*$c=$d; в PHP нет уже готовой функции которая посчитает вам сумму двух чисел и умножит ее на третье число, для этого мы можем использовать комбинацию вычеслений выше указанную или создать свою функцию которая будет выдавать нам результат $a+$b*$c=$d; Создавать свою функцию имеет смысл там где мы используем указанное математическое выражение два и более раз. Если указанное математическое выражение применяется толтко один раз то нет смысла его дублировать

А ну и конечно, забыл классику жанра что обычно пишут на ООП. Устаю просто, голова не всегда выдает 100% из тех 6% что в принципе дает нам на откуп мозг. В общем только на ООП благодаря инкапсуляции, можно писать программы, а также куски кода, аля "черный ящик", которые будут использоваться многоразово. Один программист благодаря ООП написал часть кода, и вы будете использовать его под свои задачи для получения конечно результата, который вас и интересует. Но что бы оградить этот кусок кода от ваших манипуляций шаманства итд, что бы результат вас не огорчил, он применил инкапсуляцию, и программа от вас абстрагирована невидимой стеной. Хороший пример из Жизни это ДВС в автомобиле. Не все же люди знают, что с помощью педали газа они управляют дроссельной заслонкой которой регулируют подачу воздуха в в клапана, больше воздуха, больше бензина следовательно смешивается с ним, более быстрая работа всей системы, передающая усилия на колеса, и воаля, машина быстрее едет. Но что бы получать это эффект не обязательно знать как все это работает, а что бы всякое не лазили туда ка не надо, там стоит защита, в виде всяких крышечек. открываешь капот современной машины, а под капотом плоскость, образованная совокупностью крышек всего того что находится под капотом )))) В общем такая вот кутерьма, и в процедурном стиле, эту штуку не как не сделать, так как нет инкапсуляции.

На самом деле это очень интересная тема, потому что ООП по факту это не синтаксис, а это Абстракция. Разница в чем лучше писать, в процедурном стиле или в ООП будет видна со временем и приобретенным опытом. Если поставить вопрос ребром, то ООП поддерживает 3 принципа которых нету в процедурном стиле, это 3 до боли знакомых слова каждому программисту, а именно: инкапсуляция, полиморфизм, наследование. В самом начале новичку нужно вникнуть в эти 3 абстрактных понятия, и тогда он поймет чем процедурный стиль отличается от ООП. Конечно сразу можно сказать что те "приrладные" инструменты которые есть в ООП, в процедурном стиле просто не реализованы, другой вопрос, что ООП и явилось естественным развитием процедурного стиля. Честно от себя скажу, что по факту только начинаю въезжать в смысл использования ООП в PHP, так как с С++ сильно не сравнишь. Скажу то что буду не сказано рад когда постигну все тайны этой парадигмы (ООП), возможно это даже произойдет только тогда, когда пообщаюсь с программистами из США, а именно оттуда к нам все это пришло, ну или банально увижу прямую выгоду, в ООП, хотя банальная выгода уже в 3 принципах, но опять же хочу увидеть все "+" ООП, а не маленькую часть их. Есть такая вещь, только начал в ней разбираться, называется паттерны проектирования. В общем паттерны частично проливают свет на то зачем нужно ООП, потому что в паттернах оно используется. Но вот например у меня есть вопрос, если кто знает может быть ответят, можно ли попробовать написать паттерн Синглетон(одиночка) в процедурном стиле, небольшое чувство что можно есть, хотя если сразу обратится к мат. части, то паттерн это уже по факту класс, с 2 обязательными требованиями. Но может как то можно повторить этот механизм, а паттерны по факту и есть астрактные механизмы, в процедурном стиле ? Блин, но пока писал это, понял что нельзя, так как в процедурном стиле не предусмотрена инкапсуляция(защита данных), по этому по ходу дела, ООП, ООП и ещё раз ООП.