Зачем в PHP нужен ООП

[Горбушка]

Вопрос именно к ПРО. Зачем в ПХП нужен ООП?

Нужны конкретные примеры, когда без ООП реализация не возможна, либо требует значительно больших ресурсов (Вариант сократит 2 кб кода не предлагать - на 12 Мб CMS не заметно).

Ну и вторичный вопрос: зачем вообще нужен ООП? Для каких задач они используется в том же Си, какие задачи без ООП реализовать нельзя?

P.s. не надо разводить полемику, аля "нубу тут не место". Я знаю ООП, читал несколько книг по нему, но не могу понять практического смысла. Всё, что в книгах предлагают на ООП, реализуется на процедурах...

P.p.s. тема создана в разделе PHP Pro, ибо нужен ответ только профи, которые понимаю что говорят. Ответы "ООП - это круто, модно и должно быть" не принимаются и будут удаляться как набор постов.

 

[Alex.Volk]

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

 

[Extalionez]

Прежде всего хочу принести искренние извинения если чем-нибудь обижу - я не специально, чес слово.

Спойлер: Обидчивым не открывать ни в коем случае!!! (Горбушка адекватный - ему можно)

Ну во-первых сразу видно что ты никогда не работал в команде раз такое спрашиваешь. Ибо

    public $public = 'Общий';
    protected $protected = 'Защищенный';
    private $private = 'Закрытый';

и т.п..
Про интерфейсы и абстрактники я помолчу лучше.
Во-вторых конечно можно и CMS написать в процедурном стиле, вот ток выглядеть и функционировать она будет 15-дюймовый монитор вместо экрана в IMAX кинотеатре. Более подробно это описывать нет смысла ибо факт остаётся фактом - без ООП большой проект даже 1 человек не реализует. Ибо там такая каша будет
В-третьих для меня это уже целый тип мышления. Как сказал один инопланетянин человеку в одном популярном научно-фантастическом сериале(StarGate SG-1
"Азгарды никогда бы не изобрели оружие, которое выталкивает маленькие кусочки свинца при поджоге смеси калия, нитрата и клетчатки. Мы не способны мыслить как вы"
Так и тут. Простой пример для процедурного стиля:

<?php echo 'hello world';?>

и соответственно для Объектно-ориентированного

/**
 * @author Extalionez
 * @copyright 2013
 */

class helloWorld{
    
    public $out = 'hello world';
    
    public function __construct(){
        echo $this->out;
    }
}
new helloWorld;

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

UPD(18.05.2013 14:22) :

Спойлер: небольшой прикол в тему

 

[Nei]

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

P.S. Т.к. на Php обычно именно мелкие и средние проекты разрабатываются, то польза ООП не очевидна.

P.P.S.
Кстати я бы расширил опрос:
1. Да, использую.
2. Да, использую, но не осознал пользы. (пардон за тавтологию)

 

[dandandan]

про ООП можно почитать тут: Для просмотра ссылки Войди или Зарегистрируйся вторую ссылку найти не могу.
Очень подробно стоит остановиться на наследовании. Далее уже абстракции и интерфейсы.

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

Не согласен. Пример большой cms - phpmyadmin. Раньше точно была написана с помощью процедур. Может быть за последние несколько лет что-то изменилось.

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

 

[KillDead]

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

Итак, в начале было не слово, вначале была проблема, даже ПроблемЫ. Именно это многие не понимают, когда задаются вопросом, зачем нужна какая то сложная вещь. Вот и ооп появилось как изящное решение проблем. В программировании масса задач- сокрытие данных, дополнительное поведения, избавление от дублирования кода, контроль данных и т.п. Можно ли решить это, с помощью ФП (функциональное программирование)- мой ответ да. НО, тут большое но, сможете ли вы это сделать? ООП диктует правила – ДЕЛАЙ приватные функции, НАСЛЕДУЙ, ЭТО **х УБЕРИ, это не трогай, НЕ ТРОГАЙ! Раздели по функциям и НЕ МЕШАЙ ВСЁ В ОДНО. Что даёт нам ФП- свободу действий. У нас нет ни правил ни ограничений. Когда ярые защитники ФП пишут о свободе, я всегда говорю- «вы эгоисты! Вы профи и можете спроектировать системы, а как быть нубам?» Ведь пока вы человеку прямо не запретите чтото делать, он будет это делать. В ФП это сложно сделать- система запретов только на словах. А ООП- это уже намного легче. К примеру – вывод в шаблон мы хотим сделать из класса, который предназначен только для операциями над БД и данными. Там просто не будет методов вывода в шаблон. Конечно, если система позволяет, юзер всегда сможет сделать код core::getPlugin(‘template’)->parse() но это уже сложнее, скорее всего так не будут делать 70% людей.

Сложность и недостатки ооп.

1.Сложность. Вы должны знать ООП и конкретную архитектуру так же как и язык программирования. Не знание сеет костыли и начинает казаться что ООП зло.
2.+ задача. Теперь нам не надо решать 1. задачу – как сделать сайт. Нам надо решить 2- как сделать архитектуру на ООП и 2 – решить задачу. ООП достаточно сильно зависит от архитектуры.
3.ООП ради ООП. Многие не хотят решать задачи из ТЗ. Они хотят сделать всё правильно и начинают городить огород. Я это называю ОООП – Очень ООП.
И ещё есть неприятная особенность – это правильность. Да, то, что так любят математики и теоретики- чёткая детерминированность. Это как с xml форматом- всё чётко и структурированно, даже слишком. И из за этого теряется адекватность – Представьте «Правила пользования туалетом: 1. Убедитесь что в кабинке вы один. Для этого сделайте 2 оборота вокруг оси на 180-360 градусов. Если у вас закружилась голова, постойте и передохните и сделай плавный поворот. 2. Убедитесь, что унитаз находится перед вами…»
4.Многие уже не могут просто смотреть на вещи. Но к их подходу нельзя придраться- он аргументирован.
5.Ну и наконец- мышление паттернами. Т.е. под разные задачи мы применяем шаблоны которые не всегда и нормально подходят, но изменить им мы не можем.

Достоинства

1.Чёткий подход как обходить и не наделать костылей, который прописан не просто на словах.
2.Изящные решения, которые не надо писать с 0.
Примеры… Ну, часто люди говорят что нужно написать Большую систему чтобы понять зачем нужен ООП. Я тоже с ходу не соображу пример, коорый сразу бил по ФП. Ну, разве что, из недавно увиденного:
Есть 2 модуля book, comments. Нужно сделать в обоих вывод количества. Всё. В ООП
$book->getAllCount(); $comments-> getAllCount() ;
Для фп
book_getAllCount(); comments_getAllCount() ;
что не говорите, но уродски.

 

[Горбушка]

А теперь хоре флудить и ответьте на вопрос, который задан:
Приведите пример, который реализован на ООП и не может быть реализован на процедурах.

Что касаемо "почувствуй разницу" - я могу оформить процедурку так, как никто и никогда не оформит ООП. Подготовить достойный мануал и прочее. В команде я работал, писали на ООП, потом плюнули, сделали на процедурах в 4 раза быстрее и никаких проблем с общением между друг другом... А вот опыт "натягивания" класса с буржунета на работающую CMS я даже передавать не хочу... Класс был переписан на 99%, после чего выброшен и написан процедурный код. Ну и потом, разницу почувствовал: в ООП 90% кода **х не надо =) Обрезаем всё лишнее, получаем процедуру.

Ещё раз призываю не флудить, а чётко ответить на поставленный вопрос.

 

[gres_18]

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

Такой пример привести не получится. ООП это не "более крутой php" и ни в коем случае не "серебряная пуля", а лишь один из способов организации кода. Он не делает что-то другое, он делает тоже самое что и процедуры, просто все необходимые данные и методы не размазаны по коду, а более-менее сгруппированы(зависит от разработчика).
Если пишешь в процедурном стиле и команда с которой работаешь не против этого, тогда смысла в ООП - 0.

 

[KillDead]

А теперь хоре флудить и ответьте на вопрос, который задан:
Приведите пример, который реализован на ООП и не может быть реализован на процедурах.

-- Подготовить достойный мануал и прочее.
Я не хочу читать мануал, я хочу читать код. Тем более когда подготовишь достойный мануал страниц на 200- ни читать ни гуглить по нему никто не будет только когда прям совсем припрёт.

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

Пусть есть объект 'товар', у которого есть поле Цена и метод Получить цену. От него наследуются Книга, Мяч и Игрушка. Цена формируется у каждого по своему

class tovar {
 
    protected $price = 0;
 
    function getPrice() {
        return $this->price ;
    }
 
}
 
class Book extends tovar{
    function getPrice() {
        if(isLikeBook()){
            return $this->price + $this->price/100 ;   
        }
       return $this->price;
    }
}
class Ball extends tovar{
    function getPrice() {
        if(date('d')%2){
            return $this->price + $this->price/50 ;   
        }
       return $this->price;
    }
}
class toy extends tovar{
     
}
// выводим их 
while ($row = $db->gelAllRows()){
 
$item = fabrika::getObj($row['classname'], $row);

echo $item->getPrice() .'<br />';
 
}

Вот как такое написать чтобы вывести цену для всех товаров на ФП?

 

[Горбушка]

Вооот, теперь я получил ответ на свой вопрос. Спасибо.

Оставлю только 1 коммент:

Я не хочу читать мануал, я хочу читать код.

Я тоже так хотел, но когда открыл WordPress пришлось читать доки... Найти где там этот проклятый echo для меня оказалось слишком сложной задачей.