Одно из моих самых слабых мест это ООП, ни разу их не использовал в своих программах. Обхожусь без них, хотя понимаю что без глубокого понимания ООП в будущем мне не обойтись, уважаемые знатоки, придумайте для меня задачку (не очень навороченную для начала) на примере которой можно было на практике понять ценность самого ООП, думаю я не один такой и найдутся еще "зеленые человечки" для которых будет полезна эта тематика. Благодарю. С уважением, Greenman.
Есть несколько графических контролов: Код (Text): 1. <input type='text'> 3. <textarea> 4. <input type='check'> Есть несколько типов данных : коротка строчка (до 255), длинная, целое число и флаг: Сделать классы с таким интерфейсом: PHP: <? abstract class My_Value { abstract function __construct ( $value, $title, $desc ); abstract function to_html(); }; $vars = array(); $vars[] = new My_Int(5, 'Int', 'Int desc'); $vars[] = new My_Bool(true, 'Bool', 'Bool desc'); $vars[]= new My_Text('blabla', 'Text', 'Text desc'); echo "<table>\n"; foreach($vars as $val) { echo $val->to_html(); } echo "</table>\n"; ?> И чтоб получилось Код (Text): <table> <tr> <td>Int: </td> <td> <input type='text' value='4'> <div>Int Desc</div> </td> </tr> ... </table> Задача идиоткая но может поможет хотябы тем, что перехочется просить задачи.
1/ человеку требуется задача, решение которой продемонстрирует превосходство ооп над традиционным стилем. задача с постановкой "Сделать классы с таким интерфейсом" нихрена не продемонстрирует. нужна задача, которую можно решить обоими способами (и при этом не из пальца высосанная, а реально значимая), которую ооп позволит решить более оптимально 2/ [flame started] ооп на самом деле -- лишь концепция разработки (одна из многих), которая в большинстве случаев лишь усложняет код, делает его менее понятным, более медленным. добавление лишних уровней абстракции очень редко помогает в разработке и уж почти никогда -- в поддержке чужого кода
Если большинство случаев - это разработка блогов и домашних страничек, тогда +1. Если задача более серьезная, тогда -1. Смотреть выше. Лишних - да. Абстрагировать надо не по принципу - "чем больше абстракции, тем лучше", а в действительно подходящем случае. Или тут имеется ввиду - "введение классов как способа абстрагировать решение"?
хороший блог написать -- задача очень серьёзная. не каждый сможет обеспечить хороший функционал, скорость и масштабируемость. кстати, использование ооп для разработки сложных систем я как раз и не одобряю. пугает только. хотя, может, я "просто не умею их готовить"... но и не стремлюсь сильно. по моему глубокому убеждению, ооп функциональность была добавлена в пхп 5 (реализация ооп в пхп 4 вообще не рассматривается) только для облегчения перехода джавистов и мелкомягких. чистая коммерция, тасскать. сам пхп от этого не выиграл. программы, написанные в традиционном стиле, мне кажутся понятнее [моё субъективное мнение], а работают быстрее [проверьте сами разницу в выполнении функции или метода класса, исполняющих идентичный код]
На самом деле ООП в PHP не такой уж и слабый, как кажется. Всё дело в понимании данного подхода при программировании - в этом вся суть. Ну и нужно понимание того, когда оно к месту, а когда нет. Простейший пример - классы для работы с базой данных. Что даёт традиционный подход? 1). Облегчает выполнение рутинных операций. 2). Позволяет организовать дебагинг, обработку ошибок и.т.д. Что даёт подход при использовании ООП (правильном использовании, хочу заметить) по сравнению с традиционным? 1). Все служебные переменные находяться внутри класса и глобально не видны. 2). Нет необходимости объявлять через global такие вещи как $database_connection_id, массив с дебаговой информацией, массив ошибок и.т.д. Вообщем любые переменные, которые необходимы более чем в одном методе + полная свобода в выборе имен этих самых переменных. 4). Такой же свободный выбор имён для методов класса. 5). Деструктор - при завершении/аварийной остановке скрипта деструктор класса может выполнить определённые действия, как минимум закрыть соединение с базой. Ещё многие вешают откат транзакций туда в случае ошибки. Я не говорю уже про наследование, которое кстати изают очень многие. Реализуете базовый модуль а потом его расширяете через наследование всеми необходимыми методами в пределах конкретной задачи. Многие просто не имели действительно серьзного опыта более-менее продолжительной работы с ООП, поэтому и не очень понимают концепцию и как надо работать с ООП. Такой-же подход как и к процедурному программированию какраз и убивает всю выгоду - мыслить ндо не функциями, а объектами. Думаю многие сталкиваются с такой проблемой, что у них плохо получаеться разделить задачи между несколькими объектами - запихнут всё в один объект, вот и получаеться, что это тоже самое, что написать фаил с функцияфми и сделать include. Бессмысленно использовать OOP если ваш проэкт вряд-ли наберёт больше 6-10 тысячь строк. Другое дело когда у вас много модулей, довольно много всяких shared классов - вот тогда то вся прелесть ООП и проявляеться. Именно большие системы удобно делать, потому что именно здесь проявляеться удобство того, что все переменные и методы могут называться как угодно в пределах одного объекта, не боясь что такая переменная уже объявленна каким-нить другим модулем. З.Ы. Если кому интересно, нынешний проэкт занимает 2,82 MB (2 962 723 bytes) когда (PHP + html шаблоны c PHP вставкамии и JavaScript), 54 модуля, 7 shared класса и 8 контроллеров. Сюда не включёны gettext переводы.
Как мне кажется, ООП специально и разрабатывалось для того, чтобы увеличить верхний предел размера исходного кода. Ведь для каждого подхода есть свои пределы. Иначе бы все сидели сейас и писали на asm'e. Но этого не происходит, т.к. на нём не напишешь очень много кода. Вывод один: ООП действительно нужен, только в очень масштабных проектах
Sergey89 Не только в масштабных. Вообще в серьезных проектах. Т.к. если проект потребуется расширять, ООП - это та спасительная зацепка за которую можно ухватиться.
Но! это сугубо техническая точка зрения. Факторов очешь много — и для человеческого фактора, и командной разработки в частности, ООП дает крайне много.
Горбунов Олег А на много ли быстрее? Помоему разница там принебрежительно мала. Если код написан правильно, то какая разница оформлен он в виде объекта или набора функций - время вызова функции/метода пренебрежительно мало по сравнению с временем работы скрипта. Так что лично я считаю это бесмысленным аргументом. Sergey89 Davil Не просто маштабных или серьёзных. Серьёзный проэкт может быть в объёме кода и небольшой и проще будет написать на функциях. ООП надо использовать для модульных системах - там он очень удобен. Позволяет делать некоторые выкрутасы, которые хоть и под силу с функциями, но будет весьма гемморойным. К примеру, у нас в основном все модули наследуют ModuleCore, однако для некоторых модулей у меня присутствуют специальные shared модули, которые содержат в себе методы, необходимые для нескольких модулей, и эти модули наследуют эти классы-прослойки. Очень удобно к примеру для системы ограничения доступов. У меня так в форуме бумтайма сделано - есть класс-прослойка, который содержит пару методов, которые нужны исключительно для форумов и методы по проверке доступа к форуму/теме, следовательно в самих модулях о таких вещах, как выборка инфы о том, где находиться юзер сейчас я не беспокоюсь - всё делает модуль-прослойка
В данном случае я имею ввиду серьезность типа - система, а не серьезность типа отправка email с корпоративного сайта.
При написании программ все мы сталкиваемся с вопросом организации структуры и понимания, что вообще должна делать программа и как. Как четко выстроить логику приложения и потом легко модернизировать/ добавить функционала. Большинство форумов , не исключая этого, показывают, что множество балбесов пишут вообще не понимая как это работает и перебором вариантов подбирая что вроде бы работает как надо. ООП - это именно способ организации работы, позволяющий легко и быстро писать проекты любой сложности, одному или в группе, заранее делая наглядным возможности и способы модернизации. Он полезен и в малых и больших проектах. По скорости - в некритичных участках часто применяя ООП для ясного разделения логики приходится немного уступать в скорости. Это не минус, а плюс, и в структурном подходе можно делать тоже самое и тоже с пользой, если б там так же хорошо было видно логику приложения. И в структурном подходе приходилось добавлять вложенные запросы, чтобы быть уверенным в результате работы независимо от изменений в других местах. Гордиться, что вот тут выиграл миллисекунду, но зато черт ногу сломит, не стоит. Вылизать скорость в критичном участке с примененим ООП можно так же, как и в структурном подходе. Хотя это не всегда делают, чтобы оставить логику ясной и четкой. Другое дело, что это совсем другой способ самоорганизации и способ думать, на него надо перестраиваться, если уже привык к "тупому" структурному подходу (кто уже пытался что-то выстроить, на ООП переходит достаточно легко, понимая зачем это надо), многие этого не любят.
Уважаемые профи, много доводов здесь было в защиту ООП, спасибо, что высказали свое мнение. Но меня, честно говоря, ненамного приблизило к понимания ценности ООП. Теоритические выкладки ваши меня еще раз убедили, что разумение ООП полезно (а никто и не сомневался). Но! Этот топик создавался именно для "въезжания в ООП" на практических задачах. Будем считать, что теоритическая прелюдия была введением. Как в рекламе "мясо мясо давайте". С уважением!
Adamant любую задачу можно решить многими способами. а поскольку, как уже сказано выше, ООП имеет смысл в больших и серьезных проектах, о какой задаче может идти речь? Может быть проектирование и создание портала, или электронного магазина, или распределенной корпоративной системы? Возьмите любую из этих задач и попробуйте решить с помощью двух подходов - ООП и структурного. Тогда станет ясно, что ООП отличается от пложения функций тем, что формирует Объектную систему схожую с ассоциативными понятиями создателя оного приложения, поэтому код становится более читабельным, его легче поддерживать и расширять систему в целом становится проще и приятнее чем при использовании структурного подхода.
Спасибо за совет. Думаю топик выполнил свое предназначение и может быть завершен (или нет?). Еще раз с уважением.
Adamant, лови задачу: требуется реализовать возможность работы с различными субд (например, mysql, sqlite, txtsql) или хотябы с различными драйверами субд (ext/mysql, ext/mysqli, pdo_mysql), да так, чтобы с одной на другую можно было переключиться изменив всего одну строчку в конфиге. зачем это нужно? ну, например, пишешь ты простенькую гостевую. о том, куда её будут ставить - неизвестно. php может быть как 4 так и 5 ерсии. мускул может быть как 4 так и пятой, а может и вообще отсутствовать. а работать должно!
Во всех. не надо. Надо просто начинать писать с помощью ООП. Хоть галерею или библиотеку. Я могу что-то накатать на популярное объяснение принципов ООП, но тут начнут спорить по посторонним вещам и совсем человеков напугают.
ооп -- один из стилей программирования. используя его можно писать и хорошие и плохие программы. так же как и используя традиционный подход. насчёт масштабности проектов я не очень понял фишку. по-вашему получается, что если масштабный проект написан без применения ооп, то он уже ущербный какой-то по-умолчанию? технологии надо использовать аккуратно, а не потому что они есть. регулярные выражения вон тоже можно влепить куда угодно, но так же не делают! хоть они и предназначены для обработки текста, есть более эффективные методы. Sergey89 по поводу эволюции языков я согласен. писать большую систему для предприятия на асме -- странноватый выбор. хотя и нет ничего невозможного для ищущего разума . но пхп -- язык довольно высокого уровня для интранет-приложений. а уже сама концепция сетевого приложения даёт нам огромный выигрыш при создании системы -- вся инфраструктура уже на месте, только кодируй бизнес-логику. на чём она будет закодирована -- пхп, ява, асп -- уже абсолютно не важно. использовать для этого ооп или нет -- личный выбор разработчика. я, например, считаю, что бизнес-процессы легче описывать и реализовывать алгоритмически, а объекты для меня -- строки таблиц. и какие бы мне диаграммы наследования потом ни нарисовали, как бы ни прятали данные, как ни модифицировали в классах-наследниках функциональность базовых классов, при разработке системы я получаю данные от пользователя и заношу их в базу. затем считываю их из базы и вывожу в нужном формате. насчёт зацепок для расширения проекта. единственная зацепка -- мозг в голове архитектора. он должен спланировать масштабируемую систему. ооп не гарантирует масштабируемости. помнится пару лет назад мы с одним уважаемым человеком пытались расширить функциональность одного из hibernate-классов (на яве было дело). ну не устраивал стандартный обработчик. а все нужные нам переменные были объявлены как частные. пришлось корячиться с исходниками и переопределять доступ. жутковато стало. в то же время, когда ко всем глобальным структурам данных можно обратиться напрямую -- это не может не радовать. Psih насчёт класса для базы данных. данные соединения вы прописали в классе. при подключении к базе вы инициировали класс, объявили переменные подключения. подключились. вышли из метода. данные подключения никуда не делись, они в памяти системы. но вы их не видите. они, знаете ли, объявлены приватными. и чего вы добились? кстати, а почему бы и не объявить глобально параметры подключения, массив ошибок и прочее? или оттого, что вы их "сокроете" они перестанут существовать? если я не смогу записать или считать информацию иначе как посредством вызова функции -- это что, удобно? или быстро? или памяти меньше ест? проблем с именами переменных или функций у меня никогда не было (3,5 мб исходников набил за последние 4 года). аварийная остановка скрипта всегда обрабатывалась через set_error_handler. а то что мыслить надо не функциями, а объектами -- это я уж никак переделать не смогу. не в смысле, что я мыслю функциями (мой мозг оперирует, скорее, идеями и образами), а в том смысле, что мой мозг мыслит сам по себе, просто потому что он мозг и его программировал не я. распространённое заблуждение. на самом деле не существует такого способа. легко и просто проекты любой сложности не пишутся. вообще ни одна хорошая вещь не делается легко и просто, а требует скрупулёзного планирования, кропотливой работы, внимания, опыта, предвидения, долгой и нудной отладки и ещё массы вещей.