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

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

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. имеет смысл рассматривать более стандартные задачи, чтобы не возникало лишних вопросов типа "а есть состояние у объектов, возвращаемых фабрикой?", "какие объекты используются для работы с лабораторией?" и т.д. ООП ведь имеет смысл использовать и для стандартных задач?


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


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