Изя ШниперсонВ моей практике на проектах
при программиновании на PHP возникали проблемы -
не закрытые соединения с СУБД Oracle.
Но это наверно все же из-за криворукости авторов.
Нанимать опытного PHP программиста было дорого и решили заставить
писать программу тетку, которую заставили выучить PHP за 2 месяца.
Сроки по проекту были не критичны но была важна экономия денег.
(Тетка была штатной работницей, но по своим обязанностями не очень напрягалась и на нее решили переложить PHP).

В командной разработке и еще когда важны сроки исполнения проекта, кончно Java равных нет. Потому что в разработку языка вложены большие ресурсы а PHP это типа открытый проект.

Конечно бывают ситуации, когда проект не большой - реализуем одним или двумя людьми и для срок исполнения не так важен. И если компания хочет съэкономить, то тогда нанимаются студенты читавшие книги про PHP за $500.
PHP сам решает, разрывать ли соединение с Oracle.

NotGonnaGetUs Kachalov
и еще раз приведу код на PHP с использованием SimpleXML который делает ТО ЖЕ САМОЕ
видимо только мне кажется что на PHP получилось короче


Если уж наезжать, так наезжать по полной :)

Код на java будет выглядеть примерно так:


Ты будешь смеяться, но я предпочту вариант java, а не PHP, потому что:
1. Действия с файлом и dom явно описаны.
2. Обработка ошибок не представляет проблемы: ясно что и откуда может отвалиться.
3. Избыточность буковок компенсируется наличием мощных IDE (читай IDEA), которые позволяют автоматически добавлять import'ы, полные имена методов и списки возможных параметров, а так же устранять дублирования (like getValue(NodeList nodes, int i)) простым нажатием на shortcut'ы.
4. Всех задравшее ООП позволит написать util'ные методы один раз и далее использовать теже самые 3 строчки, что и в примере на php (не забываем о поддержки автоматического рефакторинга).

Просто нет смысла считать символы :/
То, что вы написали на Яве. Можно практически один в один написать на PHP(5 версия). Смысл будет тот же. А можно забить на ООП и написать обычным структурным подходом без ООП.

NotGonnaGetUs РидикPHP не вымрет никогда. Если Zend введет графический интерфейс, то вымрет все остальное.

Да, да.
Повторять эту мантру следует каждый день по утрам и вечерам.
И тогда...

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

Пока твоя работа сосредоточенна вокруг создания хтмл-ек ты не сможешь понять о чём тут все говорят. Серьёзно.

Микрософт хорошо пиарит свои продукты. И есть у них и хорошие проги (мне так кажется).

Моя работа писать прогу (задачу) под web. Да я юзаю при этом PHP на нем проще это делать. Про ООП я в курсе. HTML-ки это способ показать инфу. Я не дизайнер, не сайтостроитель (хотя понаделал я их уже достаточно). Ява интересна. .Net ставил, пробовал. Не понравилось.

NotGonnaGetUs Ридик
То, что вы написали на Яве. Можно практически один в один написать на PHP(5 версия). Смысл будет тот же. А можно забить на ООП и написать обычным структурным подходом без ООП.

Я не писал никакого ООП в примере, на который ты ссылаешься.

Что такое ООП по твоему? ;)
Просто Ява это ООП. В ней нет обычного структурного кода. Всё ООП и ООП погоняет. В PHP есть выбор. ООП - если просто, то для меня это обертки функционала (кода).

Кувалдин Роман
Не всегда, но зачастую. Но тут скорее интересно, знакомы ли с ними конкретно вы?

Про трудности чего вы хотите услышать. Трудности модернизации, копошения в чужом кале (коде)?

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

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

Кувалдин Роман
Нифига не факт. Быстрее всего будет работать статический HTML.

Согласен.

Кувалдин Роман
А куда деваться выучившимся спецам? Переучиваться? А смысл? Они сделают то же самое и не хуже. Просто появится еще одна возможность для выбора.
Ведь из-за того, что появился GWT, ни Struts, ни JSF, ни ASP.NET не сдохли?

PHPже задавил всех в webe в сфере сайтостроительства. Если дотянется до интерфейса нормального, то и там победит.

Кувалдин Роман
Скорее "пеРЕделать, чтобы потом не ФАКаться". Советую все же почитать Фаулера. Ибо после таких слов становится видно, что с серьезной разработкой в команде вы не знакомы.

Да да и еще Рихтера в придачу.
Может быть и не знаком.

Кувалдин Роман
У нас в свое время была система, написанная на PHP. Несколько десятков килобайт кода, который худо-бедно работал. Но когда его надо было модифицировать - за голову схватился в первую очередь тот самый человек, что писал его полтора года назад. В результате все было переписано на Java

А я не переписываю просто так без команды. Работает и ладно. Лень знаете ли.

Кувалдин Роман
Аксиома: все, что ты сможешь написать на любом языке программирования, может быть написано на ассемблере.
Грамотное ООП просто экономит время при написании и ПОНИМАНИИ программы.
Я не против ООП. Вещ отличная.

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

Я доработки своего функционала делаю без проблем и без ООП. Главное не забыть чего там к чему)

NotGonnaGetUs
Обёртки функционала - это процедуры и функции.
Процедуры и функции сгрупированные по какому-то признаку - модули (ваше определение ООП).

На самом деле, ООП рождается из объединения двух концепций - модуля и абстрактного типа данных. Процедуры и функции превращаются при этом в "обслуживающий персонал" для данных. Всвязи с этим меняется способ формирования решения задач. Вместо определения последовательности выполняемых действий, производится вычленение действующих в задаче абстракций, выяснение отношений между ними и распределение обязанностей. Стабильность абстракций относительно изменений в постановке задачи приводит к тому, что вероятность повторного использования кода значительно увеличичвается.
Чтобы понять это, нужно увидеть как это работает на практике. Причём не на детских задачках, а на реальных (слушайтесь vfabr'a %)).

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

Я объяснил по-простому без модных терминов. Мне кажется разобраться в кривом ООП коде сложнее, чем в кривом так скажем перемешанном коде. Согласен если когда-то кому-то этот ООП впился в одно место и жив, посей день значит удобно кому-то, а кому-то нет. К примеру, PHP написан на С.
А тратить время на придумывания методов и свойств объекта не всякая контора хочет и делает это в основном от безысходности, так как считает, что PHP (и аля язык) не способен решить их проблемы.

vfabrРидику (кстати странный ник не Радик и не Риддик) к сведению

если начинаешь усилено пытаться использовать ООП парадигму (кстати она не лучше и не хуже функциональной она просто другая) то для ее осмысления и полного понимания требуется обычно от 5 до 7 месяцев при условии что 5 дней в неделю 8 часов в день усердно пытаешься что либо делать и делать это ОО

ПыСы
В Объекте на мой взгляд самое главное это Данные, а методы ну куда уж без них ;-)
Да надо заняться как-то плотнее. В принципе моя ЗП и работа меня устраивает и это я думаю максимум для PHP. Вот и думаю надо что-то еще, чтоб ее поднять мож когда-нибудь.

Зашедший[quot Ридик]
Вот этим и отличается кустарная и промышленная разработки, что нет и не может быть одного "супермастера", имеющего полный набор знаний о серьезном продукте. Поэтому его разбивают на различные подсистемы, создают фреймворки, стараются максимально отделить представления от данных - делают все, чтобы можно было быстро освоить какую-то часть/подсистему и изменять ее независимо от остальных частей. А сайтик интернет-продаж пяти видов открыток и двух видов тетрадок с портретами Бритни Спирс можно и на коленке без всякого ООП и прочих ненужных вещей типа постановки/автотестирования/рефакторинга сбацать, конечно.

А сайтике речь не идет. Вы видимо не представляете себе PHP и ООП вместе. Я прекрасно представляю, о чем вы хотите сказать. Видел-работал-дорабатывал систему написанной на PHP с ООП. Видимо начинал ее писать любитель ООП или обернул ее. Вот там блин приходилось изголятся. А БД была да не особо большой таблиц 120. В итоге эта система загнулась и нас всех уволили)))
Сейчас пишу без ООП, но контроль меньший на новом месте. Не пидалируют на ООП, а платят больше и не сидят, ссади и не смотрят весь день в монитор как на прежнем месте.

Илья Муромец РидикЯ объяснил по-простому без модных терминов.
Можно объяснить по простому, а можно правильно :)
Тонкая разница.

Извините меня ради бога!