Читаю Котерова & Костарева и не могу понять, какой вообще прок от использования ООП, если всё тоже самое можно сделать функциями и массивами, и это будет гораздо проще и читабельней? Пока у меня складывается такое впечатление, что ООП это просто лишнее усложнение кода. Достойной области применения классов я для себя не нашёл, разве что хранить в них данные. Вот например, локали я держу в двумерном массиве $lang, который подключается частями, из разных файлов. Пусть там будет 3 записи для примера: $lang[nav][main] = "Главная"; $lang[nav][forum] = "Форум"; $lang[nav][guestbook] = "Гостевая"; Для удобства, в коде скрипта можно создать синоним $nav =& $lang[nav], а после того как работа с этой частью массива закончена, я просто делаю unset($lang[nav]);unset($nav) и память освобождается. При использовании ООП, количество писанины увеличивается, квадратные скобки заменяются стрелками ->, и какая от этого выгода в итоге? Мы экономим память? Мы ускоряем работу скрипта? Объясните мне дураку, область применения ООП и в каких конкретных случаях он может быть полезен. =\
Пока не возникнет потребность в ООП, понять его необходимость будет сложно. Объекты, в отличе от массивов, могут содержать скрытые данные для внутреннего использования, а также функции, которые предназначены ТОЛЬКО для этих объектов.
Функции тоже могут содержать скрытые данные для их внутреннего использования, а так же возможны локальные функции внутри функций - разве нет?
извращение. неудобно, непонятно, трудно модифицировать и поддерживать в дальнейшем. классы и объекты созданы для того, чтобы удобно и централизованно хранить все данные и функции, относящиеся к конкретной тематике. Пока не за...шься работать со сложными конструкциями на основе функций, ООП не поймёшь
Freakmeister Не надо тогда лезть пока туда. Объектно-ориентированное программирование - это лишь одна из парадигм, определяющая особый подход к решению задачи. Можно использовать функциональную парадигму. Сам РНР написан на Си, языке, который не поддерживает объектно-ориентированный подход.
Области применения: промышленное программирование, создание программных систем Более того, оно там является фактическим стандартом. Вы стотыщтриллионный посетитель, который хочет, чтобы ему в рамках срача на форуме это объяснили. Используйте его и поймёте зачем оно. Хотя я вижу, что вы изначально агрессивно против него настроены, тогда не используйте. ООП - говно.
когда поработаешь в команде с кодом в десятки тысяч строк - поймешь весь прок и всю прелесть разработки.
Код (Text): класс колесо { функция конструктор (№ колеса) { $this->number = №; $this->diameder = db.... } функция крутиться (угловая_скорость) { возврат $this->diameder * угловая_скорость; } } класс мотоцикл { функция катиться { угловая скорость = db... скорость = 0; for ($i = 1; $i < 3; i++) { колесо = Новое колесо($i); скорость += колесо->крутиться(угловая скорость); } возврат скорость/2; } } А теперь напишите в процедурном виде с функциями. Написали? Молодцы. Но вдруг приходит понимание, что у колеса могут быть другие функции - блокировка, торможение (когда угловая скорость уменьшается). Дописали, ок. Получилось, что в каждую функцию нужно передавать № колеса и делать одинаковый делать запрос в базу для выборки диаметра. Хм.. много когда -> рефакторинг. Вынесли выборку диаметра колес в функцию "катиться". Ок. Внезапно приходит понимание, что помимо диаметра и номера, у колеса еще может быть ширина, тип резины. Добавили в запрос к базе. Теперь, помимо номера, у нас передается многомерный массив в функцию. Теперь появляются физические параметры сцепления резины, а так же данные тормозных колодок. И все в разных таблицах БД. Теперь придется передать уже 4 параметра в функцию "крутиться". Спустя некоторое время параметров становится 6. Появляется путаница, начинаешь забывать порядок, дефолтные величины. Начинаешь понимать, что проще обойтись без функции "крутиться", проще реализовать алгоритм работы функции "крутиться" в функции "катиться". Реализуешь. Блок кода больше, его труднее читать, но зато он проще. Через некоторое время вспоминаешь, что бывают мотоциклы с тележками. т.е 3 колеса. Быстро копипастишь код еще одного колеса. Обана! Мотоцикл летает, че за фигня?! Да 3 колесо-то не ведущее! Делаешь костыль, все работает. Спустя Спустя Спустя Получаешь три файла, каждый по 5 тысяч строк. Любая правка вызывает тысячу багов по всему проекту. Новый функционал практически нереально внедрить. Спустя... Переписываешь проект на ООП. P.S. goshale style 8)
Kreker Вся проблема подобных объяснений в том, что они(обычно) оторваны от действительности. Ну где ты будешь реализовывать мотоцикл? Особенно в PHP? Смысл ООП я начал понимать на 5 курсе (хотя объясняли нам его на 3). К тому времени я уже написал пару систем автоматизации(в базу, из базы, статистика) на Java... в процедурном стиле (по сути). А на 5 курсе возникла задача типа: Есть 7 станков. Есть 5 видов деталей. Есть таблица которая говорит сколько времени на каком станке какая деталь обрабатывается. Есть критерий выбора следующей детали для станка. Надо посчитать всякие величины: сколько всео времени уйдет на обработку, среднее время простоя каждого станка и т.п. Вот тогда я понял, что у меня есть класс "станок" и 7 его объектов. Класс "деталь" и 5 его объектов. Когда я выделил эти классы составить алгоритм всей программы оказалось в разы проще.
Проблема непонимания таких объяснений в отсутствии абстракции на начальных стадиях программирования. Что мне мешает это сделать? На php не только пишутся форумы с сайтами-визитками. Смысл ООП я начал понимать на 2 курсе, когда я пришел в проект, где его использовали. В первые же дни понял. Хотя мне никто его не объяснял, ибо я учусь по другой специальности, а единственный информатик-программист не смог объяснить, для чего все это нужно.
Kreker, хороший пример, стало более-менее понятно.) Но пока я не увижу конкретной области примирения, наверно так и не пойму удобство использования ООП до конца. Попробую разобраться в сабже на примере движков. Всем спасибо за помощь.)
Freakmeister Лучше не "движок", а объектно ориентированный фреймворк. Советую Yii - там будет понятно и применение ООП, и необходимость в применении нормального дебаггера (взамен print_r) и применение нормальной IDE
Freakmeister и это будет гораздо проще и читабельней зачем трахать красивых баб. ведь можно трахать бородатых сибирских лесорубов. и это будет гораздо женственне и сексуальнее. тупотроллинг или дебилизм? =) загадка...
igordata, первая мысль реально про троллинг была Freakmeister, представь ситуацию. Есть у тебя мир, в котором только ты, сидишь на белой мраморной бесконечной плите и над тобой небо, на которой нет ничего, что могло бы привлечь твоё внимание. Если закапываться глубже, то ты можешь понять, что на самом деле это окружение очень сложное, там есть атмосфера, законы физики, химия, и еще невесть что. но тебя это мало волнует. Вот это есть среда программирования. Если ты в этот мир приносишь задачу типа "Мне нужно распарсить rss ленту 1 раз", то реально ты берешь какашечку, кладёшь её мраморную плиту, и ботинком размазываешь её по мрамору - готово. Быстро и просто. Если задача "Мне нужно распарсить rss ленту N раз", то пишешь функцию подачи какашечек на мрамор и делаешь крутящийся ботинок на швабре, который синхронно всё это добро размазывает. Если тебе когда-либо понадобится масштабировать эту конструкцию, то будет проще создать её заново. А теперь представь ситуацию, что тебе в этот мир сбрасывают 30 видов животных и растений. И тебе нужно описать, как они взаимодействуют друг с другом в режиме реального времени. Ты тратишь месяц и описываешь процедурным стилем эти 30 видов. Потом тебе сбрасывают еще 30 других видов, которые совсем не похожи на те, что были до этого. Надо всё делать заново. Если генетически эти виды меняются, то ты будешь код допиливать до старости. Реально же на ООП получилось бы, что тебе нужно было бы описывать только различия между ними, не описывая схожего. Используя наследование можно легко перестроить начальный вид, изменив все унаследованные от него виды, не разрушая код. Ситуация резко усугубляется, когда количество видов идёт на тысячи.
titch Я дополню, с разрешения. Суть даже не в описании "видов животных", а в действиях. Их и над ними. Я слабо представляю как в процедурном стиле описать Фабрику. Freakmeister - в ООП можно работать с данными, даже не зная какие это данные будут. Т.е. я знаю что с ними точно можно провести операцию(выполнить метод класса), но не знаю какие у меня данные(объект инстанцирован динамически). Короче, пока сам не поработаешь, всё равно не поймёшь
единственное преимущество ооп - меньший запар мозгов прогеров как следствия - время написания и размер кода. объяснять парадигму ООП надо начинать не со слова объект, а с понятия "инкапсуляция". тогда оно все мягко как свечка от геморроя заходит в мозг и растворяется в нем.
Ок - пример.) У меня есть класс - пользователь, у которого есть свойства - id, name, rights, color. Все его свойства просчитываются внутри класса функциями, ну кроме id например, которое просто берётся из сессии. В коде какой-то страницы я многократно обращаюсь к каждому из этих свойств через пользователь->name например и при этом, многократно происходит обращение к функции, которая каждый раз выполняется, лезит в БД и вытаскивает имя пользователя по его id. Так? Если же я использую процедурный метод, то обращение к записи делается через массив пользователь['name'] и функция вытаскивания этого значения нужна всего раз. Результат - скрипт работает быстрее. Вот что меня более всего смущает в использовании ООП.
Freakmeister ну да, зашибись. а если тебе надо передавать юзера со всеми настройками по всем функциям и дергать у них там разные методы, то хзхз что лучше. имхо вобще рулят статик классы.
Можно брать каждый раз (если нужен реал тайм). А можно сохранить в свойство в конструкторе. А можно лезть в базу если свойство не установлено. Можно брать каждый раз (если нужен реал тайм). А можно сохранить в элемент массива при инициализации. А можно лезть в базу если элемент не установлен.
1. Статических классов в РНР вообще не существует, а вы обсуждаете их, как будто они и впрямь есть 2. ВСЕ классы глобальны по праву рождения. Исключений нет.