Тут можно говорить абстрактно или приводить конкретные технические реализации.
Мне больше нравится первый вариант.
Во первых, я считаю, главное приемущество, перед стандартным для PHP, процедурным подходом, - в более четком структурировании кода.
Когда проект вырастает из 500 строчек кода в хотябы 5000, при процедурном подходе это значило бы полное его переписывание (если кодеру не наплевать на качество кода, конечно). В случае с ООП, мы будем заниматься не переписыванием, расширением функционала существующего кода. Ну и в итоге, с ООП мы получим приемлимый для дальнейшего расширения код, а в случае с процедурным стилем очередную WAP CMS...
ООП код много легче портировать, не даром ведь все библиотеки - это класс, либо набор классов. В случае с PEAR, там еще интереснее, куча наследований и переиспользований API уже существующих классов.
Например, сейчас я сильно жалею, что в Gmanager functions.php написан в процедурном стиле, расширять его довольно непросто, т.к. это влечет за собой переписывание кучи кода.
Ну и вообще,
http://php.net/oopИз технических примеров, приведу последнее, чем пользовался и мне это показалось интересным.
Код:
| span style="color: #0000BB"><?phpclass Test{ public $PDO; // Собственно конструктор public function __construct ($db, $other) { // Присваиваем переменной объект PDO // Теперь у нас доступен PDO из нашего класса $Test->PDO->query('SELECT 1'); $this->PDO = new PDO($db, $other); } public function __get ($name) { // А в данном случае, это такая обрезанная реализация сингелтона // Если объект PDO нам нужен всегда (ну допустим это так), то Smarty нет, и в данном случае объект создастся только при первом его вызове $this->Smarty = new Smarty; } public function __call ($name, $arg) { // А тут мы реализуем логирование // Вызываем некой "несуществующий" метод и выполняем то, что заложено в логику + еще что-то на ВСЕ такие как-бы "несуществующие" методы switch ($name) { case 'one': $this->PDO->query('SELECT 1'); break; case 'two': $this->PDO->query('SELECT 2'); break; } $this->setLog('Вызван ' . $name); }}?> |
Или вот еще, недавно только узнал, что стандартные функции PHP для работы с датами работать корректно будут только с датами до 2038 года
Пруф (Смотерть Notes)
Выход - ООП реализация в виде встроенного класса Date из 5-го PHP. А в случае с ошибками, он кидает эксепшены, что так же заставляет нас пользоваться и ими
К слову, я работал в команде с JAVA программистами и, например, у них там на эксепшенах может быть построена логика программы, а не только завершение работы, как это часто делают в PHP.
Сначала я думал, что эксепшыны - лес дремучий гггг
После прочтения статьи
http://habrahabr.ru/blogs/php/58687/ как бы понял для чего они.
У меня только в 1 месте исключения используются - подключение к БД
Исключения в моём понимании - более крутая и ОО замена функции die()
на хую вас вертів
