Сколько не бился, так и не смог понять, зачем в php нужен ООП.
Ведь любые задачи можно выполнить без его использования.

Чем объект лучше ассоциативного массива?
Чем метод лучше обычной пользовательской функции?

Слышал такой довод, что так якобы удобнее. 
Чем удобнее, если нужно писать несколько строк лишнего кода, который впринципе ничего не делает?

Для примера приведу реализацию "объекта и метода" без использования классов:

Я думаю, правильнее было бы ставить вопрос так: "Необходимо ли ООП программисту?"

Согласен, но так как других языков я не знаю, то 
поставил вопрос конкретно о php

Во первых: как мне защитить допустим Машку Машкову от junior programmer и дать открытые функции для управления обьектом и его свойствами?

Во вторых: если есть Запорожцев штук 100 марок к примеру каждому Запорожцу писать свойства и функции работы с этими обьектами 100 раз!Если Вы рефакторили какую то функцию , которая влияет на свойства всех Запорожцев, это надо исправлять во всех 100! марках Запорожцев!

А если Запорожец динамически изменяется и от этого изменяются все Запорожцы ...

Можно много ещё найти плюсов к ООП.

 Совсем нет, для домашней странички можно и без него обойтись. А можно и без PHP даже.

ООП можно использовать в языках, где классы и/или объекты отсутствуют. Но зачем их эмулировать в языке, в котором они присутствуют?

Во втором варианте ты засоряешь глобальную область видимости (можешь случайно создать два объекта с одним и тем же именем)

Согласен, ошибся. Такой пример вообще не работает.

Мне думается, автор имел ввиду, нсколько часто встречаются в типичных для РНР задачах сто марок запорожцев.

Нет как защитить именно эти свойства 



Они доступны для любого программиста.
Если закрыть их функцией то они же становятся доступными только в области видимости данной функции.
Это сильно ограничивает использование такого метода организации особенно при рефакторинге.

PS: В приведённом примере Вы не защитили свойства обьекта от бесконтрольных изменений. 

Это сообщение отредактировал(а) Sentox - 2.8.2009, 14:22

Кажется я начинаю понимать всю силу и важность ООП.

ООП позволяет защититься от следующих недопустимых в реальном мире операций,
тем самым улчушая процесс моделирования.

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

вот такой код будет быстрее


чем функциональный на пхп (так как в пхп указателей нету, например: в perl есть (копировать можно))

Это сообщение отредактировал(а) gcc - 2.8.2009, 15:24

Давайте вернемся к нашей Машке.
Ради такого случая, решил прочитать и понять, как создаются классы и методы.

Написал класс. 


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

Это сообщение отредактировал(а) NLspieler - 2.8.2009, 15:01

Добавлено @ 15:05

Прочитать про PHP5 и кодить в нём.
Существуют области видимости свойств public, protected и private.
В нашем случае private и protected не дадут это сделать.

PS: Вы используете PHP4

Добавлено @ 15:10


Это сообщение отредактировал(а) Sentox - 2.8.2009, 15:13

вот тут вот кропаль есть, я там спрашивал

Глупая постановка вопроса.

Автор спрашивает зачем нужно в РНР если можно обойтись ас. массивами. Но при этом забывает, что в с++ тоже можно сделать ас.массив.

ТС почитай что такое ООП, зачем оно, где его надо применять, а где нет, возможно вопросы отпадут, потому что есть разные ситуации - разные решения.

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

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

Смотря на старый код понимаю, что то, что делал 2 недели, сейчас могу сделать за день. И не представляю код без ООП.

А начиналось все с J2ME: надо было разработать свои контроллы.

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


по-приличнее не придумал примера?

И как же ты "договоришься" изменять массив через функцию? Намного проще использовать объекты в таких ситуациях, и ненадо извращения придумывать.

а что, ты никогда не придерживаешься никаких соглашений?


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

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

необходимости в ООП синтаксисе как таковой не вижу. просто может красивее так. Хотя опять же на вкус и цвет...

по поводу разбития на подзадачи - это наверное самое главное) как говрил наш Физик - "Самое сложное в решении задачи это грамотно разбить ее на части. А потом решение этих частей по отдельности даст нам искомый ответ"

Этого можно добится используя обыкновенные функции.



Пока что две причины использования ООП в php, которые я понял:

1. Пример с Машкой: невозможномсть изменения свойств в обход методов.
Тем самым достигается дополнительная защита от ошибок.

2. Наследование. Хорошая возможность ООП. 
Но все равно, мне трудно представить себе задачу, требующую реализации этого средства. 

 Сделай сайт на фреймворке. Потом подумай, во сколько раз дольше бы ты его белал без FW.

но вообще-то это не заслуга ООП



думаю немного читабельнее


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


не во всех языках это возможно, не во всех языках есть модификаторы доступа


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

Это сообщение отредактировал(а) youri - 3.8.2009, 13:41

 Покажи мне хороший фреймворк без ООП ;)

Впринципе я вижу такое решение, но в функциональном стиле(т.е. тоже не процедурный подход).  И нафиг это не надо, когда есть ООП.

nerezus

щас будут тыкать в исходники друпала...    

у меня с фреймворками немного опыта, потому и спрашиваю. Паттерны ты, кстати, тоже к ООП относишь? Хотелось бы просто конкретных более-менее реальных примеров применения либо принципов ООП, либо паттернов. Или под ООП ты подразумеваешь синтаксис (классы, объекты)?

Добавлено @ 14:01

lukas, я ж не холивар тут устроить хочу. Меня интересует информация от человека, у которого есть опыт использования фреймворков

Это сообщение отредактировал(а) youri - 3.8.2009, 14:01

Ну например в гостевой книге есть такие функции для работы с БД:

  - подключение
  - добавление сообщения
  - редактирование сообщения
  - удаления сообщения
  - узнать количество страниц в гостевой книге

  - отображения определенной страницы ГК

  - добавление ИП в бан-лист
  - удаление ИП из бан-листа
  - проверка на присутствие ИП в бан листе


И зачем здесь использовать классы? Ведь задача и так уже разбита на множество простых ?

 Естественно.

 Нет. На C тоже можно писать в ООП-стиле, хотя там нет ни классов, ни объектов.

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

Как может выглядеть в процедурном стиле реализация таких паттернов как "Одиночка" и "Фабрика", например? Т.е. паттерны, это прямое следствие развития ООП, соответственно, что здесь и взаимосвязь прямая.

За темку, кстати, автору домо-аригато - улыбнуло  

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

Добавлено @ 17:21

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

а можно конкретные примеры использования в веб-программировании на ООП?


паттерны не только для ООП существуют


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


что никто уже и не помнит зачем *JOKINGLY* А если серьезно, то хотелось бы на конкретной задаче увидеть преимущества ООП. "Напишите на фреймворке" не катит, потому что не очевидно, что нельзя написать фреймворк без ООП

 Сделай на django блог(с каментами) и сравни эти ~40 строк кода(+ шаблоны) с тем, что бы ты делал на чистом ЯП.

Это сообщение отредактировал(а) nerezus - 3.8.2009, 19:59

А можно я сделаю блог с комментами на друпале не написав ни строки кода и скажу что процедурный стиль круче? )

А если серьезно, то на тривиальном примере вы разници не заметите, а готовить пример на n-сот строк вам никто не будет

 Давай. но при условии, что всю ЛОГИКУ ПРИЛОЖЕНИЯ пишешь с нуля ;)

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


Везде написано как, но нигде не написано зачем. 

Но тем не менее, кажется я начинаю понимать, зачем нужен ООП. 

Например, при разработке игры, в которой существует множество объектов, между которыми есть сложная связь, ООП безусловно нужен. 

Зачастую же, его применяют там, где он совсем не нужен и только все усложняет

 

 а я за полчаса сделал. Стаж проф. разработки 12 месяцев.
Админка каментов и постов через скаффолдинг.
2 контроллера, 2 вида, 2 модели. Модель создается ~2 минуты, вид по ~3 минуты некрасивый, контроллеры по 5 минут. Остальное время  на раздумья и питье кофе.
Это не геста, а блог. Геста в 2 раза быстрее.

Вот теперь подумай и сравни затраты.

 Это из серии "не разобрался, но осуждаю".

Пожалуйста, пример: печать фотографий. Мы печатаем фотографии в разных лабораториях, у всех у них разный формат обмена данными и в этом случае очень помогает паттерн "Фабрика", которая занимается производством объектов с нужным интерфейсом определенной фотолаборатории (в этой задаче используется как минимум 2 паттерна).


Не буду спорить на счет истории - не знаю и, в общем-то, не сильно интересно.


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


Я могу задать встречный вопрос: а вы попробуйте, а потом спрашивайте. Знаете, в процессе изучения и грамотного составления вопроса, по большей части, истина всплывает сама по себе.

Все вы забываете один момент, цель должна оправдывать средства !!!

Если нужна геста (а гесты редко могут похвастаться HighLoad-ом и даже мегабайтными я уж не говорю про гигабайтные БД) то пишется она одной рукой за пол часа, а второй рукой можно вспоминать свою девушку )))

(что удивительно готовых качественных никогда не видел, хотя честно искал, в итоге написал себе сам с базой в файле, с ноября файл БД не привысил и 30кб, модерируется в виндовом блокноте)

Если нужен блог то в 99% достаточно взять тот-же WordPress и не париться, нафига писать с нуля то что написано и написано лучше чем вы напишете за 2-3 минуты за которые скачаете и установите готовый.

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

morfus, блог был примером.
Под часть задач нет готовых продуктов. И именно эту часть и заказывают, как правило.

Так что ты не в тему влез.

Да нет вопросов. Если мне надо тулзу написать, которая обойдет хранилище картинок и перегенерит превьюшки, я этот скрипт на PHP никогда в жизни писать не буду, потому, что быстрее и практичнее sh/bash, к примеру. Но, тут скрывается очень большая подоплека: я не буду писать на PHP подобный скрипт, потому, что умею писать на том, который подходит под задачу в конкретном случае гораздо лучше.
А те, кто не умеют - будут писать на PHP. 

Странный сабж - "нужен ли ООП в PHP?". Тут был очень прав Маяковский: "Если звезды зажигают - значит - это кому-нибудь нужно...". Ребята из зенда кроплят днем и ночью оттачивая ООП в ZE2- это раз, потом не покладая рук расширяют Zend Framewok - это два. И наконец самое главное -  огромное к-во людей пользуется ООП именно в PHP и именно сейчас.

По моему ответ ясен.

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

  

По моему он повторяет мой

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


дело не в "положили в ротик", меня интересует скорее, что именно дает ООП (в контексте php). А так, я найду. Просто можно было бы обсудить. Сомневаюсь я, что все осознают, зачем оно нужно


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

если нужно состояние, то надо сначала вызвать функцию, которая возвращает ассоциативный массив с состоянием

Кстати, интересно, это ООП-подход или процедурный? Если ООП, то как бы тогда это выглядело в процедурном стиле?
p.s. имеет смысл рассматривать более стандартные задачи, чтобы не возникало лишних вопросов типа "а есть состояние у объектов, возвращаемых фабрикой?", "какие объекты используются для работы с лабораторией?" и т.д. ООП ведь имеет смысл использовать и для стандартных задач?


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


тоже вариант, конечно. Вспоминается фраза: "Мудрость приходит с возрастом, но бывает так, что возраст приходит один" 

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



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

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

В простейшей реализации мы будем иметь один абстрактный класс предка, который является фабрикантом и имеет возможность выбора лаборатории, добавления объекта фотографии и абстрактный метод отправки заказа, который должен реализовать потомок.



Потомок же нашей абстракции, должен будет реализовать всего лишь один метод send, который отправит данные в лабораторию.



Понятное дело, что помимо абстракции лабораторий, у нас есть еще множество классов, который предоставляют функционал для адаптации данных о лабораториях, адресах, расценках, сроках и т.п., которые мы получаем, например, через XMLRPC или SOAP сервисы.

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

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

Степанов об ООП
кроме того, такое впечатление, как будто есть только ООП и все (object happiness - не с самого начала, execution in the kingdom of nouns)