host не надо использовать классы (или любые другие супер-пупер-мега плюхи), если можете сделать без них лучше. проще и быстрее в данном случае я считаю лучше. если проект накладывает специальные ограничения (к примеру, требуется задействовать существующую объектную библиотеку), то деваться некуда и у вас выбора не будет. в этом смысле знать ооп необходимо, если вы участвуете в подобном проекте. если у вас есть выбор, то всегда старайтесь использовать технологии, которые знаете лучше, чем технологии, о которых много говорят. здесь я согласен с Davil: Amian с первым не сталкивался, не могу прокомментировать. по поводу второго могу сказать, что, во-первых, использование умл не привязывает программиста к оо-стилю программирования. во-вторых, мне самому умл кажется слишком громоздким и сложным. это и плюс (можно проектировать систему практически любой предметной области и размера) и минус (слишком высокий уровень вхождения, дорогой в обучении и использовании). практически, чтобы использовать умл по назначению, требуется несколько лет обучения и практического использования. то есть будущего специалиста необходимо сначала учить, а потом поместить в среду, где умл активно используется. в третьих, чтобы полноценно использовать умл требуется также довольно дорогостоящее по. конечно, можно использовать и визио, но в крупных проектах это будет равносильно рисованию на коленке. а роза -- вещь, которую так запросто ниасилить. ну и, наконец, главное ("медленно встаёт". специалисты по умл практически никогда не программируют. как вы правильно заметили, "проэктированием систем в больших проэктах занимаются не програмисты, а аналитики". это птицы высокого полёта (сами себя они считают элитой), у них голова занята стратегией и с такой фигнёй как реализация к ним лучше не приставать. помните анекдот про филина и мышек? а я люблю пхп. мне доставляет удовольствие не только проектирование, но и реализация, причём программирование гораздо больше, чем рисование. кстати. для большинства проектов умл и не требуется. скорее, наоборот. если бы я своим клиентам вместо последовательностей экранов показывал диаграммы классов, конечные автоматы и пр., на разработку которых я бы угробил пару месяцев, меня в этот же день просто вычеркнули бы из списка авторизованных поставщиков, посчитав, что я просто прожигаю их деньги на вещи, которыми они никогда пользоваться не будут. давайте не будем забывать, что клиенты, заказывающие разработки на пхп/мускуле ищут в первую очередь возможность снизить свои расходы на разработку и поддержку, а не дорогостоящих консультантов, рисующих красивые диаграммы. Amian, то, что вы назвали "кустарными методами", действительно, то, что надо для большинства проектов и для большинства заказчиков. крупные проекты на пхп -- большая редкость и знание умл для пхп разработчика требуется даже меньше, чем знание ооп. вы мне сейчас скажете, что это всё детский лепет недалёкого человека со средним iq, и что вы, например, освоили умл за пару дней, с самого начала в нём плавали, как рыба в воде, и за пару недель написали проект запуска экспедиции на марс. и, что самое смешное, у меня нет причин вам не поверить. однако, очень хотелось бы увидеть в этой теме захватывающие примеры из жизни, а не выдержки из популярных журналов. Davil про paint речи не было. прошу прощения, если выразился непонятно, но речь шла о powerpoint, простом инструменте, очень удобном для создания схематических последовательностей экранов (одна диаграмма на экран) и не требующей каких-либо ухищрений от заказчика (промежуточные версии можно посылать по мылу и не бояться, что заказчик не сможет их запустить). работать с ним действительно быстро, удобно и эффективно. результаты доступны клиенту, не требуют от него знания умла или какой-либо иной методологии и позволяют ему убедиться в том, что задача разработчикам ясна. заверенный документ является квинтэссенцией (извините) технического задания. программист сверяется с ним при разработке, а клиент -- при приёмке проекта. минимальная возможность расхождения мнений между клиентом и разработчиком.
Как и большенство других студентов, я долго плевался и не мог понять "нафига это вообще нужно" Специалистом по UML я себя не считаю, но все-таки отношение теперь совсем другое. В PHP ни ООП ни UML особо то и не нужны, но так как тема называется "OOP" то решил высказать тут своё мнение , чтобы не сложилось впечатление мол ООП придумали от балды и на самом деле он не эффективен На самом деле он очень эффективен для создания больших систем.
Я бы сказал даже более чем эффективен. Написать то, что я пишу щас на работе, без ооп... Нет, это возможно, но это называеться ХАОС. Представте себе 50 модулей, в каждом в среднем 6-8 методов. Есть модули где их кол-во доходит до 20-30 даже. Один мой коллега (бывший, ещё по старой работе) как-то реализовал фреймворк на функциях - повторил функционал ООП аналога. Да, у него получилось, довольно неплохо - но далеко он не ушел. Чем дальше шел, тем больше натыкался на трудности реализации, на всякие особенности и.т.д. Вообщем в итоге он плюнул и не стал мучаться - просто сделал собственную вариацию на ООП за неделю, хотя с функциями мучался почти месяц. На практике убедился в том, что я ему утверждал примерно месяца 2. С тех пор имею некоторую долю респекта в его глазах
Psih можешь показать где ты используешь ООП, где он удобнее чем использование функций, очень хочется действительно увидеть что ООП превосходит, но все что я видел, показывал что без ООП было легче и лучше. Просто некоторые из вас говорят про большую разницу между ООП и функциями, но на примере я таки не видел, покажите пожалуйста. Благодарен заранее PS На данном моментн не использую ООП, т.к. просто не вижу в нём смысла.
host Ну приведи пример самой сложной из них, елки-палки Я пытаюсь понять, надо тебе оно вообще, или нет.
У меня не было ничего сложного Но просто интересно было бы посмотреть пример сложного проекта где ООП незаменимо просто, чтобы оно стало удобнее
dark-demon я этого не пойму по той простой причине, что я всегда буду избегать его функциями и др. методами, а как вы говорите без ООП дольше, но я то буду стараться делать функциями (хотя если они даже и дольше, но я этого просто знать не буду, что с ООП было бы короче )Поэтому я и прошу наглядно показать. Благодарю всех
dark-demon да, но в ООП те же самые фунции, которые находятся внутри класса, которые функциями не называются.. т.е. какая разница ? Либо просто функции, либо функции внутри класса(методы)? Не могу уловить суть ООП просто.
host смысл не в том, чтобы запихать в класс, как можно больше функций. Основная концепция ООП - размещение данных и методов для их обработки в одном пространстве. PHP: class Object { public $cords; public function __construct($cords) { //... } public function translate($x, $y, $z) { //... } public function rotate($x, $y, $z) { //... } public function scale($x, $y, $z) { //... } public function draw() { //... } } Допустим ты захочешь сделать объект сфера: PHP: class Sphere extends Object { public function __construct($xc, $yc, $zc, $radius) { //... parent::__construct(/* ... */); } } PHP: $sp = new Sphere(0, 0, 0, 10); $sp->scale(0.1, 0.1, 0.1); $sp->draw();
Нет В объединение данных и методов их обработки под одно крыло. Писать в объектном стиле нужно имеено там, где это действительно нужно. Если ты пытаешься запихать в классы просто набор функции, то делаешь это не обдуманно, т.к. для этого есть пространства имён.
host, сила ООП в том, что код у тебя получается менее связным, то есть он у тебя разбивается на самостоятельные логические блоки, каждый из которых мало зависит от других. пусть у нас есть два объекта: Код (Text): rectangle= { width:100, height:200, angle:0, rotate: function (angle) {this->angle+=angle;} }; vector= { start: {x:0,y:0}, finish: {x:0,y:0}, rotate: function (angle) {/*пересчёт координат*/} }; и пусть у нас где-то есть функция, которой на вход подаётся некая сущность и нужно помимо всего прочего её повернуть на 30 градусов: Код (Text): function process (entity) { /*...*/ entity.rotate(30); /*...*/ } как видим функции process мы можем передавать любую сущность у которой есть соответствующий метод (которая реализует тот же интерфейс) мы можем вводить произвольное количество других сущностей с тем же интерфейсом, например, точку: Код (Text): point= { x:100, y:200, rotate: function (angle) {/*поворачивать точку? ну нах!*/} }; при этом никакой другой код править не придётся - функция process отработает нормально. в случае же процедурного подхода - пишлось бы в функцию process вставлять дополнительную проверку для выбора должного метода обработки. ООП - это прежде всего умные данные, которые сами знают какими функциями их следует обрабатывать, а наследование, инкапсуляция и прочие страшные слова - это не более чем побочные явления, которые позволяют писать меньше кода, удовлетворять параною и делать финты ушами. ps: именно поэтому я и против "типизации" и "классификации", ибо они душат идею ООП. тру-ооп - это объекты реализующие интерфейсы. в мозилле, кстати, именно так и сделано... можно создать объект с нужным интерфейсом, передать его COM-объекту и они будут дружно друг с другом работать...
)) Они не лучше или хуже — они просто разные. ) Это все равно, что спорить, что круче спортивка или деловой костюм.
host http://php.ru/forum/viewtopic.php?p=45997#45997 Изучай. На базе этого работает http://www.boomtime.lv/
Уважаемые граждане функциональщики, прежде чем кричать что ООП фигня, стоило бы хотя бы изучить его. Если вас в университет этом не учили, то мне очень жаль, ибо изучать ООП кончено лучше на примере С++, ибо он и раскрывает всю его красоту и мощь. Давно уже пора понять, что эффективность программного кода - это не только скорость его выполнения и написания,а также прозрачность, понятность и удобность. Все это должно уменьшать число ошибок, которые может допустить программист, что в конченом итоге здорово уменьшает время отладки, а также делает более простое сопровождение. ООП позволяет объединить данные и алгоритмы, которые обрабатывают эти данные в один объект - класс. Главная задача такого объединения - это правильная инициализация данных, и правильное взаимодействие с ними. В программе написаной на основе функций зачастую не так очевидно, где происходит непосредственная инициализация данных, не всегда возможно проконтролировать корректность вводимых данных. Пример. (к сожалению в ПХП я новичек, поэтому пишу на С++, но думаю вы поймете) Код (Text): struct date{ int day; //число int month; //месяц int year;//год }; Вот у нас есть структура. мы можем создать множество функций, которые могут делать такие полезные вещи, как правильное добавление дней к текущей дате (с переходом на сл. месяц), вычисление промежутков между двумя данными датами и много другое. НО! Мы не можем гарантировать, что пользователь будет вводить корректные данные (к примеру, что date.month<13). Плюс, ему может быть не всегда удобно выискивать нужные функции для работы с данными. Если же мы создадим класс, в котором будут объединены приведенные данные и функции для их обработки, а также всегда будет контроль за верностью ввода, то мы получим прекрасную программную еденицу с которой будет удобно и безопасно работать. Код (Text): class date{ private: int day; //число int month; //месяц int year;//год public: int GetDay(); int GetMonth(); int GetYear(); date AddDays(int days); date AddMonths(int months); date AddYears(int years); int DateDiffInDays(const date &secondDate); .... }; Так все понятнее и удобнее. К тому же мы "избавляем" пользователя от необходимости знать внутренне строения данных. Оно может поменятся, но сохраняя внешний интерфес мы не приведем к несовместимости со старым программным кодом. Замечу, я здесь привел простейший случай объекта. А ведь могут существовать другие, более сложные объекты, которые используют всевозможные подключения, которые нужно открывать при создании объектов и закрывать при закрытии. Более того, создание объектного кода позволяет лучше разобраться в задаче, так сказать разложить все по полочкам. Никто вас не заставляет писать все в чистом ООП везде. Вот пример, который мне приводил увтов Олег Горбунов, как ООП использовать не стоит=) Код (Text): <?PHP /** * Данный класс предоставляет информацию об используемом * итерпретаторе PHP * * @package general * @author Curguzchin Alexei (lexxscorp@gmail.com, lexxscorp@mail.ru) * @copyright 02 June 2006 */ class PhpInfo { /** * Проверяет, если версия используемого интерпретатора * меньше указанной * * @param string $version версия PHP * @return boolean */ public static function less($version) { return version_compare(self::getVersion(), $version, '<'); } /** * Возвращает версию интерпретатора PHP в виде стоки * * @return string Версия интерпретатора */ public static function getVersion() { return phpversion(); } } ?> В общем, господа несогласные, вместо того, чтобы ходить на марши несогласных с ООП, сперва выучите хотябы его основы и попробуйте что-то на нем сделать. P.S. Вы никогда не сможете узнать где нужен ООП и где он лучше функицонального подхода, пока не попробуйте написать что-то более ли менее стоющее используя ООП. После этого у вас отпаду всякие вопросы. P.P.S. Не читайте про ООП в книжках по PHP. PHP изначально был объектно НЕориентированный язык, поэтому примеры на нем смотрятся немного кривовато (но это не значит, что ООП в ПХП не нужен=) )
Не стоит приплетать другие языки. Всего прекрасно знают, что C++, Java и многие другие языки изначально объектно-ориентированные. PHP таким не был и даже сейчас в нём нет многих возможностей других ОО языков. С этим полностью согласен. Но в PHP ОО стиль следует применять к месту, а не где попало.
JStingo Читаем обе темы с самого начала Для примеров, приведенных тобой, ООП как раз не нужен: это стрельба из пушки по воробьям. Взять хотя бы твой пример с датой: вместо простого типа ты предлагаешь класс. Каждый раз, когда в приложении понадобится вычисления с датой, придется инициировать объект этого класса и вызывать у него методы. Каждый раз, когда понадобится "заглянуть" в этот объект, придется вызывать метод. Это писанина, писанина и еще раз писанина. Это как раз та самая обратная сторона ООП, о которой фанаты этого подхода обычно забывают: излишнее дробление сущностей на классы приводит к куче ненужного кода, с которым надо разбираться и который надо поддерживать.
МУАХАХХАХАХАХАХХАХАХАХА. Дорогой мой Dagdamor, для пример который я привел использовать класс очень даже и удобно и нужно. Что вы понимаете под "инициализировать объект класса"?? Он что по-другому создается в отличии от той же переменной пользовательского типа?? Размещение в стэке или в куче по-другому? Что другое? Что данные при вводе проверяются? Вы уж извините, но потом, когда вы будете рвать волосы на одном интимном месте из-за того, что данные неправильно инициализировались пусть даже в одном из 1000 случаев, вы оцените такой подход. Выигрыш в скорости почти нулевой, в качестве - огромный. Про заглядывание - это вы зря, опять таки, вы код пишите не для себя только, и если вы знаете, что менять так данные нельзя, то не факт, что другой догадается. Поэтом надо обрубить любую ненужность и излишность на корню! Про писанину: "Лучше день потерять, потом за пять минут долетим"=) Про то, что очень часто дробят не там где нужно - это не ко мне, а к психиатору. Сам лично видел генетический алгоритм написанный на с++. В тот момент мне было страшно, ибо у людей писавших это мозг был уже съеден. Все было по букве маразма, каждая "сущность" отдельный класс.... мать их.. они бы еще виртуальными функциями все оформили.... Зная такие маразмы я и привел тот примерчик в конце=) Просто пример с датой хорошо отображает принцип инкапсуляции и контроля за данными. А это пожалуй самое важное на начальном этапе изучения. А пример, который приводили в начале темы не отображает ничего, кроме как маразм применения ООП. P.S. Кстати dark-demon, поясните пожайлуста с "типизацией" я ничего не понял. Почему типизация мешает ООП? Может вы мягкокастига перекушали?
JStingo Давай сравним. Процедурный подход: PHP: $date=time(); ООП: PHP: $date=new Date(); $date->setCurrentDate(); В первом случае как-то специально создавать переменную не надо; присваиваешь ей нужное значение и все. Во втором случае нужно выполнить две операции: 1) создание объекта 2) инициализация объекта. Можно запихать инициализацию в конструктор и сделать запись покороче, но тогда будет выполняться лишний код в случае, если дату нужно инициализировать по-другому, например выбирать из БД. Неверно. Если ты сам сравнишь фреймворки, написанные на классах, и без них, ты с удивлением обнаружишь, что при одинаковом функционале и возможности расширения "классовые" системы работают на порядки медленнее; даже не в разы, а на порядки, и не любой сервер потянет посещаемый сайт, пусть даже из двух страничек, написанный на ZF или LIMB. Насчет качества: не мне тебе рассказывать, как иногда сложно "въехать" в новую систему, спроектированную на классах. Уже потом, когда ты потратишь кучу времени, чтобы разобраться, зачем оно так сделано и как всем этим пользоваться, тебе будет казаться что это единственно возможное решение и лучше некуда - пока не начнешь изучать другой фреймворк. Не надо также забывать про искажение восприятия. Я видел реально уродливые системы на классах, и их разработчики свято верили, что проще и красивее не бывает. Если в результате ты получишь крылья - тогда да. Но на практике ты получаешь обычно танк, а не крылья. Ни одна иерархия классов в PHP, что я встречал, не обеспечивала достаточной свободы, гибкости и легкости разработки. Насчет проверки данных я вообще ничего не говорил... Насчет рвания волос: при использовании классов процедура с рванием волос происходит обычно гораздо чаще, из-за ограничений, которые ООП накладывают на разработчика. Ты теряешь контроль за тем, что происходит внутри класса. Ты теряешь доступ ко многим внутренним данным класса. Ты теряешь время и нервы, в самый неподходящий момент обнаруживая, что класс А унаследован от класса Б, а ему требуется функционал класса С (единственное решение - вносить экземпляр класса С в класс А, с ним и работать; для ООП разработчиков это норма, для человека со стороны - дикий геморрой). Ты теряешь сам себя в дикой лавине мелких классов. Ты теряешь время, соображая, в какой из двух классов запихать новый метод, который работает с экземплярами обоих классов одновременно. Думаешь, я идеологически против ООП? Ничего подобного. Просто ООП надо применять с умом. Еще раз повторюсь: ОО-систем на ПХП, написанных действительно с умом, я пока не видел. Причина проста: ПХП заточен под решение конкретной задачи (обработка HTTP запроса), и все попытки "раскрутить" эту задачу на классы приводят к появлению классомонстров. В проекте сложная бизнес-логика? Тогда ООП, возможно, оправдано. Нет? Тогда игра не стоит свеч.