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

[kant]

Из своего опыта могу сказать, что единственное место, где уместно ООП - это при разработке ГУИ на десктопах (как вы изволили выразиться - при рисовании морд к БД).
А сторонники ооп используют его везде (где надо, а чаще, где не надо).

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

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

Изначально идея ООП была в том что объекты живут и обмениваются друг с другом событиями и сообщениями
В вебе ничего этого нет
HTTP-request и и в ответ - response,
Время жизни объекта - это время генерации HTML,
Нафик там ООП?

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

Собственно, врядли мы когда-ниубдь сойдемся во мнении, поскольку вы сторонник бизнес слоя на апп сервере, а я - базист, но потрепаться на форуме иногда полезно

Но хотя бы почитайте главу в книге Кайта, "developing succesful applications"

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

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

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

Большинство современных веб-приложений являются не только отображением информации, но и средой в которой пользователи работают. Хочу уточнить, что я веду речь именно про веб-приложения, а не про веб-сайты, пусть даже такие крупные веб-сайты как сайт BBC. Примерами же веб-приложений могут служить система управлениями проктами Daptiv, или например Сервис для проведения онлайн опросов и т.п. Уровень сложности такого рода систем может быть очень высок. Возможно он не сравним по сложности с телекоммуникационными биллинговыми системами, но все-же выходит за рамки рядового веб-сайта.

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

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

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

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

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

Кажется все

[ndp]

kant, все доводы, приведённые Вами, весьма разумны, но, простите за настырность (тем более что веб - не моя специфика), Вы не боитесь "выйти опять-таки на Дерибасовскую"?
В том смысле, что для этого самого изначально предназначалась Java?

[akh]

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

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

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

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

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

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

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

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

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

Сообщение отредактировал akh: 11.08.2010, 10:13:17

["0x0000"]

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

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

["0x0000"]

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

поконкретнее пожалуйста

[akh]

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

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

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

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

поконкретнее пожалуйста

здрасти...
вы не знаете что такое модульность?

["0x0000"]

akh - а вы не знаете для чего ООП? Ладно нет времени спорить

[kant]

kant, все доводы, приведённые Вами, весьма разумны, но, простите за настырность (тем более что веб - не моя специфика), Вы не боитесь "выйти опять-таки на Дерибасовскую"?
В том смысле, что для этого самого изначально предназначалась Java?

МММ, я все же не боюсь выйти на дерибасовскую, просто потому что
а) Разговор про ООП.
б) Я не вижу причин, почему я должен писать ООП код только на Java.
в) Я не считают что ООП является серебряной пулей.
г) Я не вижу причин, по которым я не могу ошибаться.

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

Да, я знаком с такой наукой "Исследование операций". Вы ведь понимаете разницу между математически решены, и практически реализованы. При математическом решении, достаточно доказать что алгоритм работает и дает ожидаемый результат, при практической реализации, надо обязательно проверить что данная реализация дает тот же результат что и алгоритм, на котором реализация основана.
ООП на этапе реализации самого алгоритма, не помогает вообще. ООП помогает когда тебе надо описать предметную область и иметь возможность быстро поменять уровень абстракции, при описании бизнес-модели.
В частности, при описании проекта и его подзадач, существуют такие задачи, которые разрывны во времени. Для алгоритма такая задача эффективно может быть представлена в виде двух подзадач, но при отображении в интерфейсе, с ней удобнее работать как с единым целым.
При работе с такого рода задачами, в разных местах системы, мне удобен разный уровень абстракции. При перерасчете плана, я ухожу в работу с чистыми данными, а при работе в интерфейсе, и формировании HTML, мне будет лишним, заострять свое внимание на том, как организована данная задача. Пользователь тоже будет работать с такого рода задачами, как с единым целым. В других местах системы
Если честно, то я не представляю как эффективно решить подобного рода задачи при процедурном подходе.

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

Как опытный пользователь, да, графический интерфейс для десктопа намного удобнее, чем веб-приложение. Но если рассматривать веб-интерфейс с точки зрения бизнеса, то веб-интерфейс имеет ряд преимуществ. Вот перечень основных, которые и делают это направление популярным.
1. Пользователь может работать со своими данными с любого компьютера.
2. У большинства людей нет потребности во всех возможностях десткоп приложений.
3. Процедура установки продукта тривиальна для конечного пользователя.

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

Рисование графиков достаточно нетривиальная задача. ООП тут как нельзя кстати. Рядовой график состоит из следующих частей. Оси(Axis), Область данных, Легенда. Оси бывают разные, с линейной и нелинейной шкалой, состоящие из данных одного столбца или нескольких, сами столбцы тоже бывают вычисляемыми. Область рисования - bar, dots, lines и так далее. Каким образом мне формировать HTML или изображение для такого рода графиков без ООП? И будет ли лучше не применять ООП.

Сообщение отредактировал kant: 11.08.2010, 12:36:13

[kant]

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

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

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

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

Большая часть кода будет разбросана по разным классам. Потому что скажем параметры на форме обрабатывает один класс, XML парсить будет другой класс, дооставать данные из БД будет третий класс, генерить HTML будет четвертый класс, выводить картинки будет пятый класс и т.д. А если еще и наследование используется то ваще пипец.

Большая часть того о чем вы написали, являлось бы нормальным и про процедурном подходе, только на каждое действие было бы парочку процедур. Процедура для парсинга XML, процедуры для получения данных из БД, формирование HTML на основание данных из БД. Не совсем понял про проблемы с наследованием. При нормальном проектировании, уровней вложения более чем 2-3 быть не должно. Это все вполне можно запомнить.

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

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

[akh]

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

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

Как опытный пользователь, да, графический интерфейс для десктопа намного удобнее, чем веб-приложение. Но если рассматривать веб-интерфейс с точки зрения бизнеса, то веб-интерфейс имеет ряд преимуществ. Вот перечень основных, которые и делают это направление популярным.
1. Пользователь может работать со своими данными с любого компьютера.
2. У большинства людей нет потребности во всех возможностях десткоп приложений.
3. Процедура установки продукта тривиальна для конечного пользователя.

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

Рисование графиков достаточно нетривиальная задача. ООП тут как нельзя кстати. Рядовой график состоит из следующих частей. Оси(Axis), Область данных, Легенда. Оси бывают разные, с линейной и нелинейной шкалой, состоящие из данных одного столбца или нескольких, сами столбцы тоже бывают вычисляемыми. Область рисования - bar, dots, lines и так далее. Каким образом мне формировать HTML или изображение для такого рода графиков без ООП? И будет ли лучше не применять ООП.

и зачем там ООП?
Создаете массивы, или ассоциативные массивы, заполняете их данными и прорисовываете графики...

[akh]

Большая часть того о чем вы написали, являлось бы нормальным и про процедурном подходе, только на каждое действие было бы парочку процедур. Процедура для парсинга XML, процедуры для получения данных из БД, формирование HTML на основание данных из БД. Не совсем понял про проблемы с наследованием. При нормальном проектировании, уровней вложения более чем 2-3 быть не должно. Это все вполне можно запомнить.

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

Сообщение отредактировал akh: 11.08.2010, 15:09:38

[ndp]

МММ, я все же не боюсь выйти на дерибасовскую, просто потому что
а) Разговор про ООП.
б) Я не вижу причин, почему я должен писать ООП код только на Java.
в) Я не считают что ООП является серебряной пулей.
г) Я не вижу причин, по которым я не могу ошибаться.

Я не спорю, я лишь говорю о том, что ООП для построения веб-приложений реализовано давно - это Java.
Учитывая пункт "б)", я так понимаю, Вы хотите чтобы на свете появилось абсолютно аналогичтое, что-то вроде "Java2".
Просто практика такого применения подобного ООП уже показала что передача необходимого исполняемого кода (будем считать байт-код Явы таковым для упрощения) всех требуемых родительских классов отрицательно сказывается на производительности и Java в массовом порядке нашла свое применение в тотчас придуманных серверах приложений...
Там ей, в принципе, и место IMHO...
А пытаясь сейчас возродить идею выполнения ООП-кода на веб-клиенте, Вы опять таки придете к первоначальным идеям Java. Так стоит ли изобретать лисапед?

Но сама идея реализации user-interactions веб-приложений на ООП чертовски заманчива . Если бы это было так же надежно, просто и функционально как для десктоп-приложений, то это сильно продвинуло бы разработку ПО...

[ndp]

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

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

[kant]

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

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

Рисование графиков достаточно нетривиальная задача. ООП тут как нельзя кстати. Рядовой график состоит из следующих частей. Оси(Axis), Область данных, Легенда. Оси бывают разные, с линейной и нелинейной шкалой, состоящие из данных одного столбца или нескольких, сами столбцы тоже бывают вычисляемыми. Область рисования - bar, dots, lines и так далее. Каким образом мне формировать HTML или изображение для такого рода графиков без ООП? И будет ли лучше не применять ООП.

и зачем там ООП?
Создаете массивы, или ассоциативные массивы, заполняете их данными и прорисовываете графики...

Есть несколько вопросов
1. Не могли бы вы описать подход, который по вашему мнению стоит использовать в веб?
2. На каком языке программирования вы пишете в веб?
3. Что в вашем понимании, является модулем, применимо к языку программирования на котором вы пишете?
4. Можно подробнее описать каким образом вы будуте обрабатывать различные варианты комбинаций осей и типов графиков. Хотя-бы следующее разделение осей на типы вертикальная/горизонтальная, линейная/логарифмическая, один столбец из набора данных/несколько. И соответственно три типа графиков: bar, pie, и cross-tab. Сама предметная область как это делать, волнует не сильно, но хотелось бы увидеть решение, которое будет эффективно справляться с геометрическим ростом вариантов, которые надо учитывать.

[akh]

1. Не могли бы вы описать подход, который по вашему мнению стоит использовать в веб?

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

2. На каком языке программирования вы пишете в веб?

Слава богу уже не пишу под веб. Даже те веб морды которые на нынешней работе были, мы переписали на сибилдере. Я вообще-то ораклист.

3. Что в вашем понимании, является модулем, применимо к языку программирования на котором вы пишете?

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

4. Можно подробнее описать каким образом вы будуте обрабатывать различные варианты комбинаций осей и типов графиков. Хотя-бы следующее разделение осей на типы вертикальная/горизонтальная, линейная/логарифмическая, один столбец из набора данных/несколько. И соответственно три типа графиков: bar, pie, и cross-tab. Сама предметная область как это делать, волнует не сильно, но хотелось бы увидеть решение, которое будет эффективно справляться с геометрическим ростом вариантов, которые надо учитывать.

Я не занимаюсь графикой. Но я не вижу никакой необходимости использовать ООП для решения ваших задач.
Как обычно пишется набор модулей/процедур/функций и в зависимости от параметров рисует что вам надо. От того что вы создадите абстрактный класс скажем Graph, определите всякие виртуальные методы, а потом от него наследуете классы bar, pie, и cross-tab, программа лучше работать не станет, и кода меньше не будет. Только больше.
Все равно нужен отдельный код для прорисовки разных типов графиков. И от того что вы его запрячете в классы bar, pie, и cross-tab, ничего не улучшится.

Я против изобретателей собственных библиотек классов. Но если они уже есть как те же JSF или Аспнет, то их надо использовать, а не изобретать велосипед.

Сообщение отредактировал akh: 11.08.2010, 16:42:47

[akh]

В частности, при описании проекта и его подзадач, существуют такие задачи, которые разрывны во времени.

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

[kant]

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

Форма 1. Описывающая запчасти, необходимые для ремонта автомобиля.
экран на котором вверху отображаются список требуемых деталей, а внизу список деталей, которые являются желаемыми.
Верхний список деталей клиент хочет видеть в голубых тонах, а нижний в светло-зеленых.
Каждый список содержит четыре столбца:
Кнопка вызывающая контекстное меню для строки. с пунктами, удалить, изменить кол-во
Наименование детали
Количество
Стоимость одной единицы.

Форма 2. Добавляющая запчасти в список требуемых или желаемых запчастей.
Все тот же список запчастей.
На этой форме клиент хочет видеть список в тех же голубых тонах, что и верхний список формы один.
Для каждой строки таблицы, отображается следующая информация
Кнопка добавляющая добавить.
Наименование детали
Текстовое поле для внесения количества добавляемых деталей.
Стоимость одной единицы.

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

Существующий список на данный момент обладает тремя параметрами, контролирующими его тображение
1. Цвет
2. Команда/меню выполняемая над элементом списка
3. Необходимость отображать кол-во как текстовое поле.

Вот как я вижу реализацию модульности системе:

Создать функцию которая будет отображать список на основе переданных в нее параметров. Этот вариант неэффективен, потому что количество параметров, по мере роста проекта, может быстро вырасти до 10. Даже при 6 параметрах, становится неудобно пользоваться такой функцией, параметры добавляются без всякого логического порядка, а пере упорядочивание параметров, дело неблагодарное и может легко привести к ошибкам. Разумеется можно вместо нашей будущую функцию с 10 параметрами сделать одну функцию которая занимается отображением списка, и несколько функций, которые устанавливают параметры отображения. Так как у нас проект форм на 50, то нам придется для функций поддерживать конвенцию по наименованиям, чтобы вновь приходящий молодняк, легко разбирался в проекте.
При поддержке общей системы наименования функций, у нас будет пара тройка функций следующего вида

list_repairparts_draw();
list_repairparts_setstyle();
list repairparts_setoption();

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

namespace repairparts
{
list_draw();
list_setstyle();
list setoption();
}

Согласитесь, что оба варианта очень напоминают определение примерно следующего класса.

class list_repairparts
{
  draw()
  setstyle()
  setoptions()
}

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

Если вы спросите в чем разница, если и в том и в том случае работать не будет рассмотрим следуюший пример:
Есть три списка отображаемых на экране последовательно.
Допусти есть параметры, которые приводят к том что список не отображается. При модульном подходе, вы можете оказаться в ситуации, когда после ввода некорректных параметров, процедура не будет отображать ни один из дальнейших списков, даже если они будут передавать правильные параметры.
В случае с модульным подходом мы можем потерять на форме 1, 2 или 3 списка, в зависимости от того в какой из списков по порядку, вы введете неправильные параметры. В случае если у объекта будет наблюдаться тоже поведение, то вы увидите два корректно отработавших списка вне зависимости от того какой список вызывается с неправильными параметрами. Это помогает локализовать ошибку быстрее и спасти свою шкуру, в случае если третий по счету список почему-то оказался очень важен для клиента.
При наличии подобного бага, ООП подход увеличивает показатели устойчивости системы к ошибкам.

----------------------------------------------------------------------------------------------------------------

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

[akh]

Форма 1. .........
Форма 2. ..............
Разумеется это только две из еще 50 существующих форм, которые будут реализованы. Копипаст исключается, так как не дай бог клиент захочет что-то добавить, то придется менять сразу в трех местах. А то и больше, если этот же список будет применяться еще где либо.

Эта фигня - типо чтоб изменить один раз и это сразу везде отразится, приводит к тому о чем я уже писал. В одном месте исправили - и начинает сыпаться в самых неожиданных местах.

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

Для разработки компонентов для ГУИ, ООП нормально подходит.
Но вы что? Свои компоненты разрабатываете? Вместо тех, что и так есть в дотнете или жабе?

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

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

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

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

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

И что? Ваши юзеры будут работать с 2-мя списками и ждать пока вы 3-й исправите? С точки зрения пользователя форма не рабочая ВСЯ, а не только один список.
И когда вы будете отлаживать вы все равно будет заходить в отладку или в логи. И искать в коде то место где третий список создается. Так что ООП нисколько не поможет в поиске бага.

[WallEnd]

Недостаточный опыт и не умение писать приложения в ООП не оправдывает ваших заявлений, как раз таки очень сложно отлаживать не классифицированный и не сгруппированный код, где все идет подряд в кашу. Путаетесь в наследованиях, так давно пора из блокнота пересесть в среду разработки. В среде разработки(типа Eclipse) именно ООП облегчает понимание огромных проектов. А про то что вылетит модуль или не модуль... если у прогера руки растут из жопы... то так или иначе код будет бажный, либо не будет совсем. Интересно было бы посмотреть, как бы вы тестили и отлаживали проект хотя бы в 600 фалов без ООПа и без применения классов. По-моему достаточно просто сказать так:
"Уровень моих знаний, и проектов не требует использования, знания и понимания ООП" все... достаточно этого, а вот обсирать ООП ну это просто по детски... давайте ещё может расскажете о преимуществах pascal перед Delphi? Тот же язык, но паскаль не ООП, а дельфи ООП...

И что? Ваши юзеры будут работать с 2-мя списками и ждать пока вы 3-й исправите? С точки зрения пользователя форма не рабочая ВСЯ, а не только один список.
И когда вы будете отлаживать вы все равно будет заходить в отладку или в логи. И искать в коде то место где третий список создается. Так что ООП нисколько не поможет в поиске бага.

Ещё раз спрошу, вы когда-нибудь писали не в блокноте. Отладка кода происходит на лету! т.е. среда компилирует его и проверяет на ошибки в момент написания... И ООП гарантирует что переменные под вуалью private будет не возможно подменить в случае бага с функцией, определяющей её. Потому что она private, внутри класса... в общем я думаю что нам всем нужно почитать поподробней тех. литературу... дабы не возникало таких споров

Сообщение отредактировал WallEnd: 18.08.2010, 16:42:35

[WallEnd]

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

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

PS
Эмм... а в чем разница между request и submit? По сути, по пунктам?

Сообщение отредактировал WallEnd: 18.08.2010, 16:54:35