За последние 24 часа нас посетили 72488 программистов и 1649 роботов. Сейчас ищет 901 программист ...

ООП

Тема в разделе "PHP для новичков", создана пользователем host, 2 авг 2007.

  1. stas_t

    stas_t Активный пользователь

    С нами с:
    24 апр 2007
    Сообщения:
    500
    Симпатии:
    0
    Адрес:
    Courbevoie, France
    host
    не надо использовать классы (или любые другие супер-пупер-мега плюхи), если можете сделать без них лучше. проще и быстрее в данном случае я считаю лучше. если проект накладывает специальные ограничения (к примеру, требуется задействовать существующую объектную библиотеку), то деваться некуда и у вас выбора не будет. в этом смысле знать ооп необходимо, если вы участвуете в подобном проекте.

    если у вас есть выбор, то всегда старайтесь использовать технологии, которые знаете лучше, чем технологии, о которых много говорят. здесь я согласен с Davil:
    Amian
    с первым не сталкивался, не могу прокомментировать.

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

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

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

    ну и, наконец, главное ("медленно встаёт":). специалисты по умл практически никогда не программируют. как вы правильно заметили, "проэктированием систем в больших проэктах занимаются не програмисты, а аналитики". это птицы высокого полёта (сами себя они считают элитой), у них голова занята стратегией и с такой фигнёй как реализация к ним лучше не приставать. помните анекдот про филина и мышек? а я люблю пхп. мне доставляет удовольствие не только проектирование, но и реализация, причём программирование гораздо больше, чем рисование.

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

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

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

    Davil
    про paint речи не было. прошу прощения, если выразился непонятно, но речь шла о powerpoint, простом инструменте, очень удобном для создания схематических последовательностей экранов (одна диаграмма на экран) и не требующей каких-либо ухищрений от заказчика (промежуточные версии можно посылать по мылу и не бояться, что заказчик не сможет их запустить). работать с ним действительно быстро, удобно и эффективно. результаты доступны клиенту, не требуют от него знания умла или какой-либо иной методологии и позволяют ему убедиться в том, что задача разработчикам ясна. заверенный документ является квинтэссенцией (извините) технического задания. программист сверяется с ним при разработке, а клиент -- при приёмке проекта. минимальная возможность расхождения мнений между клиентом и разработчиком.
     
  2. Amian

    Amian Активный пользователь

    С нами с:
    15 мар 2007
    Сообщения:
    189
    Симпатии:
    0
    Как и большенство других студентов, я долго плевался и не мог понять "нафига это вообще нужно" :) Специалистом по UML я себя не считаю, но все-таки отношение теперь совсем другое. В PHP ни ООП ни UML особо то и не нужны, но так как тема называется "OOP" то решил высказать тут своё мнение , чтобы не сложилось впечатление мол ООП придумали от балды и на самом деле он не эффективен :p На самом деле он очень эффективен для создания больших систем.
     
  3. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Я бы сказал даже более чем эффективен. Написать то, что я пишу щас на работе, без ооп... Нет, это возможно, но это называеться ХАОС. Представте себе 50 модулей, в каждом в среднем 6-8 методов. Есть модули где их кол-во доходит до 20-30 даже.
    Один мой коллега (бывший, ещё по старой работе) как-то реализовал фреймворк на функциях - повторил функционал ООП аналога. Да, у него получилось, довольно неплохо - но далеко он не ушел. Чем дальше шел, тем больше натыкался на трудности реализации, на всякие особенности и.т.д. Вообщем в итоге он плюнул и не стал мучаться - просто сделал собственную вариацию на ООП за неделю, хотя с функциями мучался почти месяц. На практике убедился в том, что я ему утверждал примерно месяца 2. С тех пор имею некоторую долю респекта в его глазах :)
     
  4. host

    host Активный пользователь

    С нами с:
    20 июн 2007
    Сообщения:
    733
    Симпатии:
    3
    Psih
    можешь показать где ты используешь ООП, где он удобнее чем использование функций, очень хочется действительно увидеть что ООП превосходит, но все что я видел, показывал что без ООП было легче и лучше. Просто некоторые из вас говорят про большую разницу между ООП и функциями, но на примере я таки не видел, покажите пожалуйста. Благодарен заранее

    PS На данном моментн не использую ООП, т.к. просто не вижу в нём смысла.
     
  5. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    host
    А какие задачи ты обычно решаешь на PHP?
     
  6. host

    host Активный пользователь

    С нами с:
    20 июн 2007
    Сообщения:
    733
    Симпатии:
    3
    Dagdamor
    В смысле какие? Бывали разные задачи
     
  7. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    host
    Ну приведи пример самой сложной из них, елки-палки :)
    Я пытаюсь понять, надо тебе оно вообще, или нет.
     
  8. host

    host Активный пользователь

    С нами с:
    20 июн 2007
    Сообщения:
    733
    Симпатии:
    3
    У меня не было ничего сложного :) Но просто интересно было бы посмотреть пример сложного проекта где ООП незаменимо просто, чтобы оно стало удобнее
     
  9. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    host, когда (если) тебе потребуется ООП - ты это сразу поймёшь сам :)
     
  10. host

    host Активный пользователь

    С нами с:
    20 июн 2007
    Сообщения:
    733
    Симпатии:
    3
    dark-demon
    я этого не пойму по той простой причине, что я всегда буду избегать его функциями и др. методами, а как вы говорите без ООП дольше, но я то буду стараться делать функциями (хотя если они даже и дольше, но я этого просто знать не буду, что с ООП было бы короче :) )Поэтому я и прошу наглядно показать. Благодарю всех
     
  11. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    вот когда тебе надоесть делать функциями ты и придёшь к ооп :)
     
  12. host

    host Активный пользователь

    С нами с:
    20 июн 2007
    Сообщения:
    733
    Симпатии:
    3
    dark-demon
    да, но в ООП те же самые фунции, которые находятся внутри класса, которые функциями не называются.. т.е. какая разница ? Либо просто функции, либо функции внутри класса(методы)?
    Не могу уловить суть ООП просто.
     
  13. Sergey89

    Sergey89 Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0
    host смысл не в том, чтобы запихать в класс, как можно больше функций. Основная концепция ООП - размещение данных и методов для их обработки в одном пространстве.

    PHP:
    1. class Object {
    2.     public $cords;
    3.  
    4.     public function __construct($cords) {
    5.         //...
    6.     }
    7.  
    8.     public function translate($x, $y, $z) {
    9.         //...
    10.     }
    11.  
    12.     public function rotate($x, $y, $z) {
    13.         //...
    14.     }
    15.  
    16.     public function scale($x, $y, $z) {
    17.         //...
    18.     }
    19.  
    20.     public function draw() {
    21.         //...
    22.     }
    23. }
    Допустим ты захочешь сделать объект сфера:

    PHP:
    1. class Sphere extends Object {
    2.     public function __construct($xc, $yc, $zc, $radius) {
    3.         //...
    4.         parent::__construct(/* ... */);
    5.     }
    6. }
    PHP:
    1. $sp = new Sphere(0, 0, 0, 10);
    2. $sp->scale(0.1, 0.1, 0.1);
    3. $sp->draw();
     
  14. host

    host Активный пользователь

    С нами с:
    20 июн 2007
    Сообщения:
    733
    Симпатии:
    3
    т.е. преимущество ООП заключается в наследовании, в отличие от функций?
     
  15. Sergey89

    Sergey89 Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0
    Нет :) В объединение данных и методов их обработки под одно крыло. Писать в объектном стиле нужно имеено там, где это действительно нужно. Если ты пытаешься запихать в классы просто набор функции, то делаешь это не обдуманно, т.к. для этого есть пространства имён.
     
  16. dark-demon

    dark-demon Активный пользователь

    С нами с:
    16 фев 2007
    Сообщения:
    1.920
    Симпатии:
    1
    Адрес:
    леноград
    host, сила ООП в том, что код у тебя получается менее связным, то есть он у тебя разбивается на самостоятельные логические блоки, каждый из которых мало зависит от других.

    пусть у нас есть два объекта:

    Код (Text):
    1. rectangle= {
    2.   width:100,
    3.   height:200,
    4.   angle:0,
    5.   rotate: function (angle) {this->angle+=angle;}
    6. };
    7.  
    8. vector= {
    9.   start: {x:0,y:0},
    10.   finish: {x:0,y:0},
    11.   rotate: function (angle) {/*пересчёт координат*/}
    12. };
    и пусть у нас где-то есть функция, которой на вход подаётся некая сущность и нужно помимо всего прочего её повернуть на 30 градусов:

    Код (Text):
    1. function process (entity) {
    2.   /*...*/
    3.   entity.rotate(30);
    4.   /*...*/
    5. }
    как видим функции process мы можем передавать любую сущность у которой есть соответствующий метод (которая реализует тот же интерфейс)

    мы можем вводить произвольное количество других сущностей с тем же интерфейсом, например, точку:
    Код (Text):
    1. point= {
    2.   x:100,
    3.   y:200,
    4.   rotate: function (angle) {/*поворачивать точку? ну нах!*/}
    5. };
    при этом никакой другой код править не придётся - функция process отработает нормально. в случае же процедурного подхода - пишлось бы в функцию process вставлять дополнительную проверку для выбора должного метода обработки.

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

    ps: именно поэтому я и против "типизации" и "классификации", ибо они душат идею ООП. :) тру-ооп - это объекты реализующие интерфейсы. в мозилле, кстати, именно так и сделано... можно создать объект с нужным интерфейсом, передать его COM-объекту и они будут дружно друг с другом работать...
     
  17. Anonymous

    Anonymous Guest

    )) Они не лучше или хуже — они просто разные. )
    Это все равно, что спорить, что круче спортивка или деловой костюм.
     
  18. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
  19. Sergey89

    Sergey89 Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0
    Psih не могу понять, в чём разница методов get и show в парсере? :)
     
  20. JStingo

    JStingo Активный пользователь

    С нами с:
    4 авг 2007
    Сообщения:
    7
    Симпатии:
    0
    Уважаемые граждане функциональщики, прежде чем кричать что ООП фигня, стоило бы хотя бы изучить его. Если вас в университет этом не учили, то мне очень жаль, ибо изучать ООП кончено лучше на примере С++, ибо он и раскрывает всю его красоту и мощь.
    Давно уже пора понять, что эффективность программного кода - это не только скорость его выполнения и написания,а также прозрачность, понятность и удобность. Все это должно уменьшать число ошибок, которые может допустить программист, что в конченом итоге здорово уменьшает время отладки, а также делает более простое сопровождение.
    ООП позволяет объединить данные и алгоритмы, которые обрабатывают эти данные в один объект - класс. Главная задача такого объединения - это правильная инициализация данных, и правильное взаимодействие с ними. В программе написаной на основе функций зачастую не так очевидно, где происходит непосредственная инициализация данных, не всегда возможно проконтролировать корректность вводимых данных.
    Пример. (к сожалению в ПХП я новичек, поэтому пишу на С++, но думаю вы поймете)
    Код (Text):
    1. struct date{
    2. int day; //число
    3. int month; //месяц
    4. int year;//год
    5. };
    Вот у нас есть структура. мы можем создать множество функций, которые могут делать такие полезные вещи, как правильное добавление дней к текущей дате (с переходом на сл. месяц), вычисление промежутков между двумя данными датами и много другое. НО! Мы не можем гарантировать, что пользователь будет вводить корректные данные (к примеру, что date.month<13). Плюс, ему может быть не всегда удобно выискивать нужные функции для работы с данными.
    Если же мы создадим класс, в котором будут объединены приведенные данные и функции для их обработки, а также всегда будет контроль за верностью ввода, то мы получим прекрасную программную еденицу с которой будет удобно и безопасно работать.
    Код (Text):
    1. class date{
    2. private:
    3. int day; //число
    4. int month; //месяц
    5. int year;//год
    6. public:
    7. int GetDay();
    8. int GetMonth();
    9. int GetYear();
    10.  
    11. date AddDays(int days);
    12. date AddMonths(int months);
    13. date AddYears(int years);
    14.  
    15. int DateDiffInDays(const date &secondDate);
    16. ....
    17. };
    Так все понятнее и удобнее. К тому же мы "избавляем" пользователя от необходимости знать внутренне строения данных. Оно может поменятся, но сохраняя внешний интерфес мы не приведем к несовместимости со старым программным кодом.

    Замечу, я здесь привел простейший случай объекта. А ведь могут существовать другие, более сложные объекты, которые используют всевозможные подключения, которые нужно открывать при создании объектов и закрывать при закрытии. Более того, создание объектного кода позволяет лучше разобраться в задаче, так сказать разложить все по полочкам.

    Никто вас не заставляет писать все в чистом ООП везде. Вот пример, который мне приводил увтов Олег Горбунов, как ООП использовать не стоит=)
    Код (Text):
    1. <?PHP
    2.  
    3. /**
    4.  * Данный класс предоставляет информацию об используемом
    5.  * итерпретаторе PHP
    6.  *
    7.  * @package general
    8.  * @author Curguzchin Alexei (lexxscorp@gmail.com, lexxscorp@mail.ru)
    9.  * @copyright 02 June 2006
    10.  */
    11. class PhpInfo {
    12.    
    13.     /**
    14.      * Проверяет, если версия используемого интерпретатора
    15.      * меньше указанной
    16.      *
    17.      * @param string $version версия PHP
    18.      * @return boolean
    19.      */
    20.     public static function less($version) {
    21.         return version_compare(self::getVersion(), $version, '<');
    22.     }
    23.    
    24.     /**
    25.      * Возвращает версию интерпретатора PHP в виде стоки
    26.      *
    27.      * @return string Версия интерпретатора
    28.      */
    29.     public static function getVersion() {
    30.         return phpversion();
    31.     }
    32. }
    33.  
    34. ?>
    В общем, господа несогласные, вместо того, чтобы ходить на марши несогласных с ООП, сперва выучите хотябы его основы и попробуйте что-то на нем сделать.

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

    P.P.S. Не читайте про ООП в книжках по PHP. PHP изначально был объектно НЕориентированный язык, поэтому примеры на нем смотрятся немного кривовато (но это не значит, что ООП в ПХП не нужен=) )
     
  21. Sergey89

    Sergey89 Активный пользователь

    С нами с:
    4 янв 2007
    Сообщения:
    4.796
    Симпатии:
    0
    Не стоит приплетать другие языки. Всего прекрасно знают, что C++, Java и многие другие языки изначально объектно-ориентированные. PHP таким не был и даже сейчас в нём нет многих возможностей других ОО языков.
    С этим полностью согласен. Но в PHP ОО стиль следует применять к месту, а не где попало.
     
  22. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    JStingo
    Читаем обе темы с самого начала :)
    Для примеров, приведенных тобой, ООП как раз не нужен: это стрельба из пушки по воробьям. Взять хотя бы твой пример с датой: вместо простого типа ты предлагаешь класс. Каждый раз, когда в приложении понадобится вычисления с датой, придется инициировать объект этого класса и вызывать у него методы. Каждый раз, когда понадобится "заглянуть" в этот объект, придется вызывать метод. Это писанина, писанина и еще раз писанина. Это как раз та самая обратная сторона ООП, о которой фанаты этого подхода обычно забывают: излишнее дробление сущностей на классы приводит к куче ненужного кода, с которым надо разбираться и который надо поддерживать.
     
  23. JStingo

    JStingo Активный пользователь

    С нами с:
    4 авг 2007
    Сообщения:
    7
    Симпатии:
    0
    МУАХАХХАХАХАХАХХАХАХАХА. Дорогой мой Dagdamor, для пример который я привел использовать класс очень даже и удобно и нужно. Что вы понимаете под "инициализировать объект класса"?? Он что по-другому создается в отличии от той же переменной пользовательского типа?? Размещение в стэке или в куче по-другому? Что другое? Что данные при вводе проверяются? Вы уж извините, но потом, когда вы будете рвать волосы на одном интимном месте из-за того, что данные неправильно инициализировались пусть даже в одном из 1000 случаев, вы оцените такой подход. Выигрыш в скорости почти нулевой, в качестве - огромный. Про заглядывание - это вы зря, опять таки, вы код пишите не для себя только, и если вы знаете, что менять так данные нельзя, то не факт, что другой догадается. Поэтом надо обрубить любую ненужность и излишность на корню!

    Про писанину: "Лучше день потерять, потом за пять минут долетим"=)

    Про то, что очень часто дробят не там где нужно - это не ко мне, а к психиатору. Сам лично видел генетический алгоритм написанный на с++. В тот момент мне было страшно, ибо у людей писавших это мозг был уже съеден. Все было по букве маразма, каждая "сущность" отдельный класс.... мать их.. они бы еще виртуальными функциями все оформили.... Зная такие маразмы я и привел тот примерчик в конце=)

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

    P.S. Кстати dark-demon, поясните пожайлуста с "типизацией" я ничего не понял. Почему типизация мешает ООП? Может вы мягкокастига перекушали?
     
  24. stas_t

    stas_t Активный пользователь

    С нами с:
    24 апр 2007
    Сообщения:
    500
    Симпатии:
    0
    Адрес:
    Courbevoie, France
    бред и подростковый максимализм
     
  25. Dagdamor

    Dagdamor Активный пользователь

    С нами с:
    4 фев 2006
    Сообщения:
    2.095
    Симпатии:
    1
    Адрес:
    Барнаул
    JStingo
    Давай сравним.
    Процедурный подход:
    PHP:
    1. $date=time();
    ООП:
    PHP:
    1. $date=new Date();
    2. $date->setCurrentDate();
    В первом случае как-то специально создавать переменную не надо; присваиваешь ей нужное значение и все. Во втором случае нужно выполнить две операции: 1) создание объекта 2) инициализация объекта. Можно запихать инициализацию в конструктор и сделать запись покороче, но тогда будет выполняться лишний код в случае, если дату нужно инициализировать по-другому, например выбирать из БД.

    Неверно. Если ты сам сравнишь фреймворки, написанные на классах, и без них, ты с удивлением обнаружишь, что при одинаковом функционале и возможности расширения "классовые" системы работают на порядки медленнее; даже не в разы, а на порядки, и не любой сервер потянет посещаемый сайт, пусть даже из двух страничек, написанный на ZF или LIMB.

    Насчет качества: не мне тебе рассказывать, как иногда сложно "въехать" в новую систему, спроектированную на классах. Уже потом, когда ты потратишь кучу времени, чтобы разобраться, зачем оно так сделано и как всем этим пользоваться, тебе будет казаться что это единственно возможное решение и лучше некуда - пока не начнешь изучать другой фреймворк. ;) Не надо также забывать про искажение восприятия. Я видел реально уродливые системы на классах, и их разработчики свято верили, что проще и красивее не бывает.

    Если в результате ты получишь крылья - тогда да. Но на практике ты получаешь обычно танк, а не крылья. Ни одна иерархия классов в PHP, что я встречал, не обеспечивала достаточной свободы, гибкости и легкости разработки.

    Насчет проверки данных я вообще ничего не говорил...

    Насчет рвания волос: при использовании классов процедура с рванием волос происходит обычно гораздо чаще, из-за ограничений, которые ООП накладывают на разработчика. Ты теряешь контроль за тем, что происходит внутри класса. Ты теряешь доступ ко многим внутренним данным класса. Ты теряешь время и нервы, в самый неподходящий момент обнаруживая, что класс А унаследован от класса Б, а ему требуется функционал класса С (единственное решение - вносить экземпляр класса С в класс А, с ним и работать; для ООП разработчиков это норма, для человека со стороны - дикий геморрой). Ты теряешь сам себя в дикой лавине мелких классов. Ты теряешь время, соображая, в какой из двух классов запихать новый метод, который работает с экземплярами обоих классов одновременно.

    Думаешь, я идеологически против ООП?
    Ничего подобного.
    Просто ООП надо применять с умом. Еще раз повторюсь: ОО-систем на ПХП, написанных действительно с умом, я пока не видел. Причина проста: ПХП заточен под решение конкретной задачи (обработка HTTP запроса), и все попытки "раскрутить" эту задачу на классы приводят к появлению классомонстров. В проекте сложная бизнес-логика? Тогда ООП, возможно, оправдано. Нет? Тогда игра не стоит свеч.