Сообщений в теме: 32

[akh]

[ Не ну такого бреда я ещё не слышал... а что такое по твоему AJAX? А как насчет динамического обновления контента? DOM И прочее... это все лажа??? Если ты ограничен в знаниях и кроме менюшек ничего не делал, этоне значит что Яваскрипт ни на что больше не способен. Учи матчасть!

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

Я делаю фотогалерею на ПХП...

с чем и поздравляю....
слава богу я этим не занимаюсь
те пару лет которые я провел на аутсорсе одной американской конторы (делали их короративный сайт) мне хватило.

А вообще если в дискуссию влезают персоналии сводящие обсуждение к оскорблениям, то пришло время перестать в ней участвовать...
Думаю, не стоит опускаться до твоего уровня.

[WallEnd]

[ Не ну такого бреда я ещё не слышал... а что такое по твоему AJAX? А как насчет динамического обновления контента? DOM И прочее... это все лажа??? Если ты ограничен в знаниях и кроме менюшек ничего не делал, этоне значит что Яваскрипт ни на что больше не способен. Учи матчасть!

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

Я делаю фотогалерею на ПХП...

с чем и поздравляю....
слава богу я этим не занимаюсь
те пару лет которые я провел на аутсорсе одной американской конторы (делали их короративный сайт) мне хватило.

А вообще если в дискуссию влезают персоналии сводящие обсуждение к оскорблениям, то пришло время перестать в ней участвовать...
Думаю, не стоит опускаться до твоего уровня.

Я и не опускался! Чем я вас оскорбил, уважаемый? Тем, что сказал о вас правду? Как вы можете судить о том, в чем не соображаете? Пишете на оракле? Пишите, бога ради, СУБД это СУБД, ООП в вебе, это ООП в вебе... вы просто начали всех убеждать, а я написал что я с вами не согласен и написал почему, что вас задело? Если вы против ООП'а... да пожалуйста, просто найдите грамотное обоснование своей точки зрения, а пока что из ваших постов я увидел контекст "Веб-программинг, это фигня примитивная там ООП не нужен..."
Далее цитаты:

Для корпоративных приложений веб вообще не использовать, (а с другими я чесно гря не работаю)
Вообще я работал с JSP и ASP, Немного разбирался с аспнет. С пхп знакомился в свое время. ПХП мне больше понравился, если не использовать ООП.
мой подход:
Тупо берешь обрабатываешь реквест, анализируешь параметры на форме или query string, вытаскиваешь данные с бд и генеришь HTML.
Никаких своих классов, разве что уже готовые, типа рекордсета. Генерация HTML, насколько я знаю, вопрос в аспнете или в JSF - тривиальный. Им даже заморачиваться не стоит.

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

Кстати это один из ключевых моментов из-за которых я считаю, что ООП в вебе нафик не нужно.
В десктопном интерефейсе объекты живут до тех пор пока программу не закроешь, они могут обмениваться сообщениями и реагировать на события. Два процесса запущенные одновременно могут обмениваться друг с другом данными. А также хранится состояние. Выбранные галочки элементы списков и т.д. в одной программе никуда не исчезают, если вы переключитесь на другую.
В вебе этого нет. request-response. Время жизни объектов - это время генерации страницы. После того как респонс ушел, все объекты убиваются. Зачем там ООП?

Блин да лучше в трех местах поменять. А из моего опыта - юзеры всегда хотят только в одном месте поменять, но так чтобы все остальное не менялось.

Если я не шарю в Оракле, то я о нем и не пишу... ИМХО...

[Gonzo]

Да уж... кто-то забивает гвозди молотком, кто-то микроскопом, кто-то головой, а кто-то задницей (последнее прошу не принимать близко к сердцу, да и не близко тоже)...

Не вижу смысла кому-то что-то доказывать (каждый стоит на своей точке зрения и всё тут), но делать мне сегодня нечего, потому и напишу...

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

Короче ушёл далеко от того что хотел написать:
Если кто-то забивает гвозди микроскопом и так ему проще и у него это получается и поставленную задачу он решает, то не стоит набрасываться на него и обращать его в свою веру в молоток... да и он не должен пропихивать своё ноу хау всем остальным... это опять же бесполезный спор на тему что лучше - арбуз или лопата

[Gonzo]

з.ы. а вобще было бы интересно собрать из таких вот "доказывающих свою правоту разработчиков" одну группу и дать им один большой проект и чтобы получилось в итоге:
1) Завалили бы проект к чертям собачьим, потому что вместо того чтобы что-то делать, с пеной у рта доказывали бы друг другу что лучше ООП или функционально-ориентированный подход...
2) Или всетаки бы пришли к какому-то соглашению...

[darkfire]

Поддерживаю
глупый спор

[WallEnd]

з.ы. а вобще было бы интересно собрать из таких вот "доказывающих свою правоту разработчиков" одну группу и дать им один большой проект и чтобы получилось в итоге:
1) Завалили бы проект к чертям собачьим, потому что вместо того чтобы что-то делать, с пеной у рта доказывали бы друг другу что лучше ООП или функционально-ориентированный подход...
2) Или всетаки бы пришли к какому-то соглашению...

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

Но спор из серии что лучше АСП, ПХП, или Перл... Ололо пыщщщьь пыщщщьььь!!!111

[Gonzo]

Я и не говорил о том что молоток это скажем так "левовведение", просто каждый решает поставленную задачу тем инструментом который он знает (и хрен вы его переубедите, пока он сам не дойдёт до того, что гвозди ЛУЧШЕ забивать молотком, а рассмотривать размножение бактерий всё же ЛУЧШЕ под микроскопом)... кароче в топку этот спор

[WallEnd]

Я и не говорил о том что молоток это скажем так "левовведение", просто каждый решает поставленную задачу тем инструментом который он знает (и хрен вы его переубедите, пока он сам не дойдёт до того, что гвозди ЛУЧШЕ забивать молотком, а рассмотривать размножение бактерий всё же ЛУЧШЕ под микроскопом)... кароче в топку этот спор

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

Мое мнеие все же что каждая технология находит свое применение... ИМХО)

Сообщение отредактировал WallEnd: 22.08.2010, 15:35:12

[Gonzo]

Можно, но невсегда нужно

з.ы. Каждая технология находит свое применение... это да, тут я с вами полностью согласен...

[T. Anre]

Для корпоративных приложений веб вообще не использовать, (а с другими я чесно гря не работаю)
Вообще я работал с JSP и ASP, Немного разбирался с аспнет. С пхп знакомился в свое время. ПХП мне больше понравился, если не использовать ООП.
мой подход:
Тупо берешь обрабатываешь реквест, анализируешь параметры на форме или query string, вытаскиваешь данные с бд и генеришь HTML.
Никаких своих классов, разве что уже готовые, типа рекордсета. Генерация HTML, насколько я знаю, вопрос в аспнете или в JSF - тривиальный. Им даже заморачиваться не стоит.

Я видел Контролеры в тысячи строк. И при этом не было намека на использование Моделей. А Представления, являющиеся частью Контролеров просто приводили в ужас. И это не Рефакторится, господа. Любое малейшее изменение бизнес-требований к системе требовало десятков человеко-часов разработчиков и тестировщиков.
Бывает, что случайно спросишь у основных разработчиков про TDD, дык они думают, что это про HTML.
Что TDD это тег ячейки таблицы. А XP - это плохо потому, что похожа на ХРень.
Про сетевые диаграммы и риски, что по части управления проектами, так это все лесом.
Планы - это небрежно исчирканный список на пыльном блокноте. Да, и управления изменениями или интеграцией - это неизвестная переменная, которая определена только для буржуев, а в нашей локале - undefined.

Я не защищаю ООП, но связка Web-Forms + MVC Framework + ORM Framework очень лаконична и прекрасна. Технологии .NET и Java cами по себе уже ООП. И использовать в ООП-ориентированной среде не ООП как-то неправильно. Даже всеми известный public static void Main(String[] args) очень смахивает на шаблон Command.

В ООП все прекрасно отлаживается:
- ~ 20% покрытие тестовыми классами с применениейм классов Заглушек
- обработка исключений и логгирование
- сценарии для селены.

Я люблю "блюдо спагетти", если это пища, а не термин.

[Developer.Net]

на счёт сопровождения ООП ориентированных приложеннии в Visual Studio есть инструмент - Architecture Explorer, кот. дает возможность в графиеческом виде, быстро с ориентироваться в чужом коде!

[parrker]

Даже всеми известный public static void Main(String[] args) очень смахивает на шаблон Command.

Как красиво Надо будет на досуге в курилке подкинуть эту тему.

[vfvtnjd]

букаф многа - смысла мало

1. Потому что современные веб-приложения обладают сложной поведенческой логикой и необходим инструмент моделирования сложной логики.

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

Ну и чего там сложного?
Вы знакомы с такой наукой "Исследование операций"?
Математически, такие задачи давно решены, есть такие методы как CPM и PERT (один из них даже вроде в НАСА разработали)
и без всяких ООП

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

Формирование графиков, на странице отчетов. Существует около 6-8 типов графиков, отображающих данные. Они все достаточно стандартны, Bar, Plot, SCatterPlot, таблицы и т.д. Любой график настраиваем и имеет свои параметры отображения, на одной странице пользователь может разместить любое количество графиков, В том числе и одинакового типа.

во-1-х, для всякого рода графических приложений оконный интерфейс однозначно лучше, и еще надо спросить зачем такие приложения на вебе делать?
во-2-х, опять же не вижу чем ООП облегчит задачу?
и вообще какая нафик поведенческая логика? в вебе юзер может сделать только request (или AJAX request) и submit. JavaScript в браузере я не рассматриваю, т.к. он ничего серьезного сделать не позволяет. Кроме как всякие движущиеся менюшки.

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

вы когда нить пробовали тестить и отлаживать проект написанный с применением ООП?
Это полная ...опа. Почему? Да потому что эти классы: (наследованные, переопределенные и прочая хрень) приводят к тому что код преплетается друг с другом, так, что большинство ф-ций состоят из одной строчки которая вызывает другую ф-цию.
Вот когда такой код отлаживаешь то ныряешь из одной ф-ции в другую до тех пор пока не забудешь откуда ты вообще начал. Большая часть кода будет разбросана по разным классам. Потому что скажем параметры на форме обрабатывает один класс, XML парсить будет другой класс, дооставать данные из БД будет третий класс, генерить HTML будет четвертый класс, выводить картинки будет пятый класс и т.д. А если еще и наследование используется то ваще пипец.
Это то что я видел на практике.
А разбиение большой системы на подсистемы решается без всяких ООП, если понимать что такое модульность.

А вот здесь вы кажся очень даже заблуждаетесь...