Форум PHP

я не пойму преимуществ ООП в php. Какие скрипты с помощю ООП можна написать? Если можна то напишите любой скрипт на php с ООП(или дайте ссылку на скрипт)

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

Я пока не стал писать в этом стиле долго не мог понять в чём фишка. Просмотрел очень много материалов, но ни одна, извиняюсь за выражение "б...ть" не сделала акцент внимания на том, что переменные объявленные внутри класса являются глобальными по отношению к функциям объявленным в этом классе. То есть если функция , имеет переменную которая сформирована в другой функции, то её (переменную) не надо передавать как параметр . Единственное условие, функция где формируется переменная должна быть обязательно вызвана. Я вообще недавно в программировании, создал всего два сайта диски-шина.рф, golos-naroda.ru(правда с нуля) , но видя очевидность такого преимущества, переделал оба сайта в стиле oop. Код стал намного компактнее и понятнее. Да и изменения вносить стало на порядок легче.
Приведу пример:
<?php

class test
{
public $a = 'a';
public $b = 'b';
public $c = 'c';
public $d = 'd';
public $q = '-';
public $sum;
public function f1()
{
$this->sum = $this->a.$this->q.$this->b;
return $this->sum;
}
public function f2()
{
$this->sum = $this->sum.$this->q.$this->q.$this->c.$this->q.$this->d;
return $this->sum;
}
}
$_sum = new test;
$sum1 = $_sum->f2();
$sum2 = $_sum->f1();
$sum3 = $_sum->f2();
echo "<br />sum1=$sum1";
echo "<br />sum2=$sum2";
echo "<br />sum3=$sum3";
?>
результат:
sum1=--c-d
sum2=a-b
sum3=a-b--c-d

А теперь представьте, что вам понадобилось в каждую из функций добавить параметр, а функции часто вызываются. Подозреваю что в oop ещё много таких фишек. Но если не пытаться программировать в этом стиле , то вряд ли можно будет их узнать.

Что-то мне даже сложно представить такую книгу по ООП, в которой не рассказано про единое внутри класса и отдельное от всего проекта пространство имен.

Тем не менее, вы и сейчас, додумавшись сами, либо не правильно понимаете, либо не правильно формулируете.

> То есть если функция , имеет переменную которая сформирована в другой функции
прочитав это, я было подумал, что сейчас вы откроете мне Америку! Ан нет.

То, что вы называете "переменной сформированной в другой функции", на самом деле называют свойством объекта. И формируются (создаются) они не в функциях, а в момент создания объекта (экземпляра класса), т.е. когда вы пишете "$_sum = new test;", сразу после этого все свойства объекта:

public $a = 'a';  public $b = 'b';  public $c = 'c';  public $d = 'd';  public $q = '-';  public $sum;

созданы.

И внутри функций (методов класса) вы не формируете переменные, а присваиваете значения свойствам класса. Когда вы пишете $this-> -вы обращаетесь к классу.

А переменная сформированная внутри функции, как и прежде не доступна за ее пределами.
Если переписать одну из ваших функций:

<?php class test   {   ..............................   public function f2()     {     $concat = $this->sum.$this->q.$this->q.$this->c.$this->q.$this->d;     $this->sum = $concat;     }   }   // то $concat - это переменная, доступа к которой вы не получите нигде за пределами функции   echo $concat; // как минимум ничего не выведет. А может и Notice выдать.   // а вот к свойству объекта sum можно обратиться даже без return внутри функции.   echo $_sum->sum; // выведет значение свойства.

Не надо цепляться к терминам. Если бы я прочитал статью, подобную моей, более года назад, то сейчас мне бы не пришлось перелопачивать килобайты кода делая его более понятным и оптимизированным. То есть я просто попытался объяснить на пальцах (в терминах понятных начинающему программисту, без загрузки лишней информацией )человеку, который ещё не сталкивался с ооп, в чём его очевидное преимущество,. И то что об этом говорится во всех учебниках вы правы. Но почему тогда так много вопросов в нете на эту тему. Указанное преимущество очевидно даже в очень маленьких проектах. Хотя ГУРАМИ OOП оно признаётся только в больших . Да, один момент. Что бы переменная ( для Sfinks свойство) была доступна внутри разных функций необходимо использовать конструкцию $this->имя_переменной. Если внутри функции использовать конструкцию $имя_переменной то для разных функций это будут разные переменные. Sfinks писал об этом. Но мой вариант мне представляется более понятным.

Вообще про ООП много и подробно писалось лет 10 назад, сейчас во многих программистов эта методология так въелась, что им сложно сформулировать для начинающих базовые принципы. Это однако, нисколько не умоляет возмущения по поводу того, что методология плохо описана. Я поэтому часто советую изучать ООП не в PHP (для начала, он тут просто не до конца реализован).

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

Вообще да, в нормальном ООП довольно много любопытного, проблема ООП в PHP, что он не реализован до конца, без перегрузки операторов ООП сильно теряет в силе.

Плохо у вас все с сайтом http://диски-шина.рф/ ввел в форму поиска в поля от и до по одинарной кавычки и увидел сообщение

Database query failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '\' && price<= \') order by p_name ASC' at line 1

исправляйте. и чем быстрее тем лучше

Спасибо!!!

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

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

Честно сказать даже не стал читать всю эту тему, может быть как следсвие мой пост будет офтоп или флуд, но может быть он станет поезным кому то
Откуда взялось в 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; Создавать свою функцию имеет смысл там где мы используем указанное математическое выражение два и более раз. Если указанное математическое выражение применяется толтко один раз то нет смысла его дублировать

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

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

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

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

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

Ну альтернативы в этой среде применения 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 ... Но при этом сказать что я крутой программист, я не думаю, я не использую процедурный стиль, потому что мне не хватает мозгов подумать, все ведь и так придумали до меня ...

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

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

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

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

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