[дискуссия] Зачем применять ООП в PHP ? (На примере IPB)

Статус
В этой теме нельзя размещать новые ответы.
я не говорю про ООП вообще. Я прекрасно пользую его во Flash и без него реально было бы очень туго, я про классы в PHP
Нажмите для раскрытия...
Спасибо, поржал :D
Классы - это и есть составляющяя ООП (за исключением людей, которые собирают свои функции в классы для оформления либ).

Процедурное - оперирование линейными данными, всё просто и понятно.
ООП - абстрагирование, работа не с линейными данными, а с объектами (наборами данных обладающими определёнными свойствами), сначала не всё просто и требует определённого склада ума.

Спорить можно до усрачки, но то, что ООП-код легче поддерживать/расширять/рефакторить - это факт.

Что касается быстродействия и памяти:
1. как уже было замечено выше и железо и память на сегодняшний день "ничего" не стоят
2. надо не только руки прямо затачивать, но и задумываться над оптимизацией. Если ООП-код медленнее процедурного в 1.5-2 раза - дело не в PHP, а в коде.

Что касается читаемости кода - ИМХО, в ООП она выше в силу структурированности.

Что касается namespaces - они уже есть в PHP 5.3
 
ООП

Применение ООП оправдано только в крайних случаях. Практически все можно сделать без оных.

Что касается if else - практика говорит, что такая связка работает намного быстрее любых классов, какие бы они ни были, даже если связка повторяется множество множество раз.

Глупо применять классы, только по тому, что это современно.
 
Когда-то давным-давно была похожая полемика про Windows 95 и Windows NT. Мне вот почему-то сейчас глядя на этот топик она вспомнилась..

Дело в том, что когда у тебя на машине 16 мегабайт оперативы (за точные цифры не ручаюсь, давно было) - 95 на ней в принципе работает, хрюкает вином частенько, но работает. NT не запустится ни в жизни. 32Mb - 95 работает отлично, NT еле-еле и жутко тормозит. На 64Mb 95 работает практически так же, как и на 32, а вот у NT уже скорость заметно подросла и стала комфортной. Поставь 128 метров - и для 95 ты тупо не заметишь разницы. А вот NT уже будет работать заметно быстрее, чем 95 на 32х метрах, и быстрее чем 95 на тех же 128. И чем больше памяти докупать - тем сильнее разница в скорости. А теперь вопрос - что быстрее, 95 или NT? А если учесть что тогда среди нас школьников 128Mb ни у кого не было?

В общем я это к чему веду: Если у тебя маленький проект, то на ООП ты его будешь писать в два, а то и в три раза дольше, чем надо. Будешь заниматься тупой херней, наваляешь 300 строк никому не нужного кода, понапридумываешь каких-то левых абстракций, сущностей, в общем короче мрак. Мини-утилитки на 10 строчек на ООП в принципе невозможны (как и NT не запускается на 16 метрах). А вот чем большие по объему кода у тебя проекты, тем большее преимущество получает ООП. А проекты уровня той же винды без использования объектной парадигмы написать в принципе нельзя - ты тупо УТОНЕШЬ. Поэтому всему свое применение. Нельзя говорить что "ооп нужно использовать всегда" и нельзя говорить что "ооп - лишний никому не нужный кал".

Другое дело что в вебдеве (и в PHP в частности) большие проекты - довольно таки редкость. И какой-нибудь простенький форум или гостевую имхо все же быстрее и легче набросать "по-быстрому", чем городить огород из объектов. Даже если потом придется вносить существенные правки (а далеко не всегда это бывает нужно, кто бы там что ни говорил), может оказаться проще тупым поиском и заменой поредактить те несчастные 50 строчек кода, или даже точно так же набросать "по-быстрому" и новую версию.

Да, очень хорошо, когда работа с базой вынесена в отдельную абстракцию и ты можешь заменой одного файлика перейти с MySQL на, скажем, Postgres. Только многие ли из нас меняют СУБД как перчатки на уже готовом проекте?
 
OOП надо применять осторожно и не везде..ООП хорошо ,когда создается большой ресурс и в его разработке принимают участие несколько команд программистов..тогда каждая команда пишет отдельно свой модуль..вот здесь просто необходим ООП ,особенно если проект будет массовым те универсальным...если же делать под себя ИМХО не надо парится с ООП ,а то ваш код будет напоминать портянку индийских программистов:D ...
ну наверно самый простой пример подсчет обращений к БД На ООП -самый лучший вариант...Мне нравится процедура...меньше кода ,все логично ..только побольше функций и инклюды ,где надо..и никакого ООП....;)
 
Применение ООП оправдано только в крайних случаях. Практически все можно сделать без оных.
Нажмите для раскрытия...
С таким подходом и автомобили не оправданы - достаточно велосипедов и телег. :D
Другое дело что в вебдеве (и в PHP в частности) большие проекты - довольно таки редкость. И какой-нибудь простенький форум или гостевую имхо все же быстрее и легче набросать "по-быстрому", чем городить огород из объектов. Даже если потом придется вносить существенные правки (а далеко не всегда это бывает нужно, кто бы там что ни говорил), может оказаться проще тупым поиском и заменой поредактить те несчастные 50 строчек кода, или даже точно так же набросать "по-быстрому" и новую версию.
Нажмите для раскрытия...
Не согласен в принципе - если ты не хочешь получить в итоге мёртвый проект, ты всегда будешь вносить изменения в старый код и наращивать функционал.
Это применительно действительно к проектам, а не сайтам-визиткам.
Если код размеров в несколько сот килобайт, то процедурный подход будет оправдан, если код исчисляется мегабайтами и разрабатывается не одним человеком, то с ООП-подходом управиться намного легче.
Это раз.

ООП-код читабельнее и структурирование - это 2.

Да, очень хорошо, когда работа с базой вынесена в отдельную абстракцию и ты можешь заменой одного файлика перейти с MySQL на, скажем, Postgres. Только многие ли из нас меняют СУБД как перчатки на уже готовом проекте?
Нажмите для раскрытия...
Распространённое заблуждение - нет средств абстрагирования от БД.
Есть средства абстрагирования доступа к БД, но под разные сервера всё равно придётся писать свои SQL-запросы. Так, что одним файликом не обойдёшься.
 
ООП в отличии от процедурного метода позволяет взаимодействовать между собой не только данным, но и методам. Не знаю как это по-другому объяснить. Приведу пример.

Писал парсер сайта. Теоретически с помощью него можно парсить сразу несколько сайтов. Управление очень простое:
PHP: 
$site1 = new Parser('http://www.example.com');
$site2 = new Parser('http://www.example2.com');
Теперь из этих созданных объектов мы можем получить любые данные, которые воплотил программист:
PHP: 
echo $site1->getKeywords(); // ключевые слова
echo $site2->getDescription(); // описание
При этом внутри класс может представлять из себя очень сложную систему, но для пользователя скрываются все тонкости его работы. Чтобы получить ключевые слова и описание, надо получить контент страницы, а это — сетевые нагрузки. Поэтому нет смысла скачивать страницу два раза. Но откуда процедурный метод это может знать? Внутри объекта вы можете хранить контент страницы и скачивать его, если это необходимо (или не скачивать, если ранее он уже был загружен). Пользователю достаточно знать, как получать нужные данные и все.

Это не единственное преимущество ООП. Прочитайте про интерфейсы и типизацию, уловите связь, и вы узнаете про такое понятие как полиморфизм.

В PHP ООП не всегда раскрывает все свои преимущества. Сокрытие сложностей WinAPI с помощью ОО-стиля, когда каждое окно, кнопка, поле, полоса прокрутки — объект, заметно упрощает создание интерфейса пользователя (GUI).
 
PHP_Master написал(а):
Причём здесь лучше/хуже?
Я писал о дебильности фразы "Но откуда процедурный метод это может знать?" в контексте твоего поста.
Нажмите для раскрытия...
PHP_Master написал(а):
Полная хрень.
Особенно выделенное предложение.
Нажмите для раскрытия...
Слово «особенно» говорит о том, что и остальная часть — «полная хрень». Этим блоком текста я хотел показать одно из преимуществ ООП. Преимущество заключается в удобстве использования. Ты пытаешься сказать обратное. Я тебе предложил тоже самое сделать процедурным методом.

Голова не отвалилась, сынок?
 
Держи, папа :D

PHP: 
function load($url) {
    // загружаем URL и сохраняем его в $_SESSION['storage'][$url]
}

function getDescription($url) {
    if( !isset($_SESSION['storage'][$url]) )
        load($url);

    // получаем необходимые данные и возвращаем
}

function getKeywords($url) {
    if( !isset($_SESSION['storage'][$url]) )
        load($url);

    // получаем необходимые данные и возвращаем
}

// перед завершением работы скрипта делаем unset($_SESSION['storage']); 
// или киляем по одиночке по мере необходимости
// или просто забиваем

Сильно отличается
PHP: 
$site1 = new Parser('http://www.example.com');
$site2 = new Parser('http://www.example2.com');

echo $site1->getKeywords(); // ключевые слова
echo $site2->getDescription(); // описание
от
PHP: 
echo getKeywords('http://www.example.com'); // ключевые слова
echo getDescription('http://www.example2.com'); // описание
:D:D:D

cyberquoter написал(а):
Позволю себе включиться в дискуссию.

Вы посмотрите код VBulletin - будете плакать горче, чем от IPB :)
По поводу ООП:

1. Не нужно говорить, что он целесообразен не везде... Даже генерацию хоумпаги нужно делать с применением паттернов, ибо времена проходят. код перерабаытвается, аппетиты растут - дописывать все-равно придется. Будете разбирать весь процедурный код годика через 2 - материтцо бу :)

2. Применение ООП нельзя обсуждать, в принципе. Ибо это есть зло :)

С удовольствием поспорю с тем, кто будет оспаривать :)
Нажмите для раскрытия...
 
1. Не нужно говорить, что он целесообразен не везде... Даже генерацию хоумпаги нужно делать с применением паттернов, ибо времена проходят. код перерабаытвается, аппетиты растут - дописывать все-равно придется. Будете разбирать весь процедурный код годика через 2 - материтцо бу
Нажмите для раскрытия...
У меня есть демон, который выдаёт необходимую информацию из БД согласно поступившему запросу.
Кода всего с десяток строк.
Тоже нужно городить городушку из класов и обязательно использовать паттерны?
Чушь.
 
Понравились взвешенные высказывания Colonel Fizz Для просмотра ссылки Войди или Зарегистрируйся и
venetu Для просмотра ссылки Войди или Зарегистрируйся

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