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

Тема в разделе "PHP Pro", создана пользователем Горбушка, 17 май 2013.

?

Вы используете ООП?

  1. Да

    59,5%
  2. Нет

    24,3%
  3. Редко

    16,2%
Статус темы:
Закрыта.
  1. Горбушка

    Горбушка Ищу её...

    Регистр.:
    2 май 2008
    Сообщения:
    3.175
    Симпатии:
    2.195
    Вопрос именно к ПРО. Зачем в ПХП нужен ООП?

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

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

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

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

    Alex.Volk Охотник

    Регистр.:
    16 мар 2012
    Сообщения:
    371
    Симпатии:
    1.021
    ООП прежде всего это порядок кода, чтобы работающий за тобой человек мог легко разобраться в нем.
     
    cyber_punker нравится это.
  3. Extalionez

    Extalionez Клоун

    Заблокирован
    Регистр.:
    21 авг 2008
    Сообщения:
    368
    Симпатии:
    185
    Прежде всего хочу принести искренние извинения если чем-нибудь обижу - я не специально, чес слово.
    Ну во-первых сразу видно что ты никогда не работал в команде раз такое спрашиваешь. Ибо
    PHP:
        public $public 'Общий';
        protected 
    $protected 'Защищенный';
        private 
    $private 'Закрытый';
    и т.п..
    Про интерфейсы и абстрактники я помолчу лучше.
    Во-вторых конечно можно и CMS написать в процедурном стиле, вот ток выглядеть и функционировать она будет 15-дюймовый монитор вместо экрана в IMAX кинотеатре. Более подробно это описывать нет смысла ибо факт остаётся фактом - без ООП большой проект даже 1 человек не реализует. Ибо там такая каша будет:conf:
    В-третьих для меня это уже целый тип мышления. Как сказал один инопланетянин человеку в одном популярном научно-фантастическом сериале(StarGate SG-1:(
    "Азгарды никогда бы не изобрели оружие, которое выталкивает маленькие кусочки свинца при поджоге смеси калия, нитрата и клетчатки. Мы не способны мыслить как вы"
    Так и тут. Простой пример для процедурного стиля:
    PHP:
    <?php echo 'hello world';?>
    и соответственно для Объектно-ориентированного
    PHP:
    /**
     * @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) :
    [​IMG]:D
     
    cyber_punker нравится это.
  4. Nei

    Nei Nosce te ipsum

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

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

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

    dandandan

    Регистр.:
    7 авг 2008
    Сообщения:
    991
    Симпатии:
    267
    про ООП можно почитать тут: Перейти по ссылке вторую ссылку найти не могу.
    Очень подробно стоит остановиться на наследовании. Далее уже абстракции и интерфейсы.

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

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

    KillDead

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

    Итак, в начале было не слово, вначале была проблема, даже ПроблемЫ. Именно это многие не понимают, когда задаются вопросом, зачем нужна какая то сложная вещь. Вот и ооп появилось как изящное решение проблем. В программировании масса задач- сокрытие данных, дополнительное поведения, избавление от дублирования кода, контроль данных и т.п. Можно ли решить это, с помощью ФП (функциональное программирование)- мой ответ да. НО, тут большое но, сможете ли вы это сделать? ООП диктует правила – ДЕЛАЙ приватные функции, НАСЛЕДУЙ, ЭТО **х УБЕРИ, это не трогай, НЕ ТРОГАЙ! Раздели по функциям и НЕ МЕШАЙ ВСЁ В ОДНО. Что даёт нам ФП- свободу действий. У нас нет ни правил ни ограничений. Когда ярые защитники ФП пишут о свободе, я всегда говорю- «вы эгоисты! Вы профи и можете спроектировать системы, а как быть нубам?» Ведь пока вы человеку прямо не запретите чтото делать, он будет это делать. В ФП это сложно сделать- система запретов только на словах. А ООП- это уже намного легче. К примеру – вывод в шаблон мы хотим сделать из класса, который предназначен только для операциями над БД и данными. Там просто не будет методов вывода в шаблон. Конечно, если система позволяет, юзер всегда сможет сделать код 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() ;
    что не говорите, но уродски.
     
    duncan, 01K, o_nix и 6 другим нравится это.
  7. Горбушка

    Горбушка Ищу её...

    Регистр.:
    2 май 2008
    Сообщения:
    3.175
    Симпатии:
    2.195
    А теперь хоре флудить и ответьте на вопрос, который задан:
    Приведите пример, который реализован на ООП и не может быть реализован на процедурах.

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

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

    gres_18 Pythonобандерівець®

    Регистр.:
    26 апр 2009
    Сообщения:
    407
    Симпатии:
    206
    Такой пример привести не получится. ООП это не "более крутой php" и ни в коем случае не "серебряная пуля", а лишь один из способов организации кода. Он не делает что-то другое, он делает тоже самое что и процедуры, просто все необходимые данные и методы не размазаны по коду, а более-менее сгруппированы(зависит от разработчика).
    Если пишешь в процедурном стиле и команда с которой работаешь не против этого, тогда смысла в ООП - 0.
     
    Горбушка нравится это.
  9. KillDead

    KillDead

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

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

    Пусть есть объект 'товар', у которого есть поле Цена и метод Получить цену. От него наследуются Книга, Мяч и Игрушка. Цена формируется у каждого по своему
    PHP:
    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 />';
     
    }
     
    Вот как такое написать чтобы вывести цену для всех товаров на ФП?
     
    DrCanibal, blet, dfsoftware и 2 другим нравится это.
  10. Горбушка

    Горбушка Ищу её...

    Регистр.:
    2 май 2008
    Сообщения:
    3.175
    Симпатии:
    2.195
    Вооот, теперь я получил ответ на свой вопрос. Спасибо.

    Оставлю только 1 коммент:
    Я тоже так хотел, но когда открыл WordPress пришлось читать доки... Найти где там этот проклятый echo для меня оказалось слишком сложной задачей.
     
    DrCanibal и dorogaya нравится это.
Статус темы:
Закрыта.