Я новичок и половину того что здесь написано не понял. Но в ООП что то должно быть. Какое то преимущество которое можно описать используя простые примеры. Я так думаю конечно.

На ООП ты будешь больше кода писать
Если у тебя сайт больше, чем пару вкладок с галереей, то ты столкнёшься с тем, что в одних разделах ООП будет вредить только коду. В других - помогать.
Сначала всё будет так:
- ООП дрять, не надо ею пользоваться.
- ООП панацея от всех болезней.
- И только потом ты наконец научишься разделять, где применять, а где его не надо применять.

П.С. не разжигайте холивар со мной, мне не интересно.

_____________
Обучаю веб-программированию качественно и не дорого: http://school-php.com
Фрилансер, принимаю заказы: PHP, JS, AS (видео-чаты). Писать в ЛС (Личные сообщения на phpforum).

Разве нельзя сделать универсальные наборы функций и разложить их по файлам? Обозвать такие файлы библиотеками и вуаля... Многие паттерны можно реализовать и на прцедурке. Зато получится возможно чуть менее универсальный ферймворк, но с большой скоростью выполнения. Но таких продуктов я не встречал, вероятно, их и вовсе не существует. Ну разве что WP, но там немножко другая история. Кстати он не менее тормознутый чем та же Joomla, написанная на свирепейшем ООП. На таком диком, что там даже обертка на bootstrap создана в стиле ООП.

То есть получается в скорости выполнения разница->0. Решающую роль играет грамотное проектирование.

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

В первом сообщении вопрос про объекты.

Я считал что классы это и есть ООП, так как только классы наследуются, функцию же не наследуешь.

alex162341
1) как я писал выше - преимущество в автозагрузке. Вам не надо каждый раз инклюдить библиотеки и не надо знать где они лежат, это делает автозагрузчик.
2) как писал inpost - наследование. Правда оно очень редко где требуется, но всё же иногда выручает если используешь сторонние библиотеки. (я уже не говорю о бредовых интерфейсах и абстракциях)
3) объединение функций в классы. Допустим есть у вас настройки конфигурации и есть настройки доступа, их можно задавать, а можно получать, вот и делаете два класса config и access, в которых будут нужные вам методы (функции)

Вот на примере как это выглядит снаружи

#классы
$Config = new config;
$Config->set('title','мой сайт'); //Задали конфиг
$conf = $Config->get(); //Получили всё настройки
echo $conf->title; // выведет "мой сайт"

или тоже самое с функциями

include '/libs/config.func.php';
config_set('title','мой сайт');
$conf = config_get();
echo $conf['title'];

На первый взгляд разницы никакой, ну кроме автозагрузки, но если копать глубже, то в классах есть тот же $this, который позволяет методам использовать свойства друг друга (функциям использовать локальные переменные друг друга без использования глобальных)

Это вот как бы основное почему я начал использовать классы, там конечно еще много чего интересного и полезного, но для начала думаю вам этого хватит, что бы использовать на практике и постепенно изучать остальное.

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


_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

Можно поподробнее? Что и как вы предлагаете разделять?

_____________
PHP: The Right Way
Бесплатное обучение Symfony2

Tox: 55BB67DE54B1CB14F8C37B4F3AED64E6A45922988D22F85EF75039751F26F05460664D978F5C

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

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Всё что написали выше коллеги - неправильно. Ну, почти неправильно.

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

_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru

Подписываюсь!

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

А иначе спор бессмысленен. За вас давно уже поспорили и сделали определённые выводы умные даденьки, к которых эти овер 9000 часов есть. Выводы просты: ООП быть! Вот когда дорастёте до уровня тех самых дяденек, тогда и можете спорить, если желание ещё останется.

_____________
PHP: The Right Way
Бесплатное обучение Symfony2

Tox: 55BB67DE54B1CB14F8C37B4F3AED64E6A45922988D22F85EF75039751F26F05460664D978F5C

Вот первый признак того, что человек не понимает сути ООП. Когда он оперирует словами "процедурный стиль". Нет такого стиля.

Лично я разграничиваю физически. Двумя словами - есть библиотека функций, которые расширяют возможности PHP. Она да, подключена везде. Прямо в индексе. Соответственно ведут эти функции себя так же, как и любые штатные. Везде видны и везде работают. Ну для примера маленькая обертка:

    function htmlChars($data)    
    {    
        if(is_array($data))             
            $data = array_map("htmlChars", $data);  
        else               
            $data = htmlspecialchars($data);    
                                 
        return $data; 
    }

Позволяет обрабатывать массивы любой вложенности.

Вот для чего мне чего-то разграничивать? Всем оно надо. И если кто-то случайно напишет созвучную, интерпретатор выдаст ошибку.

Всё остальное разграничивается физически. Некоторый функционал инкапсулируется в классы. Иногда полезно даже их отнаследовать (само определение не верно по сути, даже по переводу). Расширить. Иногда интересно использовать паттерны, допустим ту же фабрику. Но это не ООП. Это библиотеки. Это инструкции, которые будет выполнять программа, если необходимо.

К примеру у меня есть класс постранички. Он лежит в библиотеках, есть пить не просит. Когда нужно, он подхватится автолоадом (тоже вопрос спорный об оптимальности) и отработает свою задачу. Не нужна постраничка - пусть лежит. Есть класс почты - соответственно. И так далее - пара десятков нужных классов в загашнике. Не в приложении, а дома, в репозитории. Понадобится - положу в либы.

Есть компоненты. Отдельные самостоятельные программки, которые пользуются библиотеками и общими данными. Они вообще никому не мешают.

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

А есть общая вьюшка, которая собрана по образу фабрики. Нужна для того, чтобы передать в родительские (и не только) шаблоны "глобальные" данные. Это вроде паттерн, но не ООП. Потому что суть прямо противоположная. Я сначала определяю что нужно делать, потом уже кто это будет делать.

Ну а остальное - обычная генерация страниц.
В контроллере достаточно написать к примеру так:

    $view = View::create('user');

    $view->assign(htmlChars($data))->run();

Мне насрать, как называются переменные в контроллерах (они кстати у меня процедурные) ибо два контроллера не могут работать одновременно. И хоть полмиллиона страниц, какая разница. И пусть полмиллиона человек работает - каждый со своим контроллером. Они никогда не пересекутся. Это же касается и моделей.

И что мы имеем.

1. Общий функционал - библиотеки. Где тут можно пересечься? В том же PHP чёт никто не пересекается)))

2. Контроллеры, модели и вьюшки у всех свои. Да, кода по объему больше. Но он работает частями. 5-6 файлов одновременно (не считая библиотек, которые не пересекаются), и это оптимальнее, ремонтопригоднее и прозрачнее. Не нужно разгребать доки с архитектурой. Она проста: контроллер -> вид <-> модель. Всё. Остальное - окружение. Ибо императив.

3. Общие данные (конфиги, ленгвичи и прочая), что тоже пересечься не может по определению.

Чего тут можно бояться?

Вот когда всё приложение - единое целое (a в ООП обычно так), тогда нужно бояться и прятаться за фиговыми листочками немспейсов. Я тут недавно посмотрел, сколько файлов подключает хваленый TWIG для обработки одной страницы и охренел. 89!!! Конечно тут зассышь пересечений. А нужно то всего распарсить "Привет, Мир!"

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

Это не прикладные программы. Там так не выйдет))) Но мы вроде тут о PHP говорим?

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.