ООП или процедурка?

bearman, речь вообще-то шла о том, что это операции, на порядки превышающие время, затрачиваемое на обработку классов.

Да, и я так понял, вы думаете, что если что-то выполняет сторонняя программа, то она не работает с базой? Мистической силой ответы из базы выдает, видимо ;)

Так что, bearman и edogs,

и осильте, что этот кэшер работает просто с другой базой данных. Какой - думайте сами. Развивайте свой кругозор ;)

А, ну-ну.

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

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

Любопытно почему такой вопрос применительно к WEB однозначно ассоциируется с PHP?

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

Либо девушка, либо не девушка. Либо пользоваться надстройкой на С(С++/ассеблер. Не знаю на чем PHP написан и знать не хочу) либо рассуждать об извращенности и неэффективности надстроек. А если уж не девушка, так почему бы не воспользваться наработками ZEND или каким другими типа Cake, CI, Cohana, YII.... Ну в крайнем случае PHPClasses.

Почему у всех прочих вопрос о необходимости ООП не возникает, а у php-программистов до сих пор дискутируется?

Если здесь пробежит Т.R.O.N. он обязательно всплывет относительно надстроек над JS. Он это любит :)

Блин, не думал, что в конце 2009 наткнусь на подобную тему :) Думал, что все точки над i расставлены были еще лет 5-7 назад. Ан, нет... Сто раз давал себе обещание обходить подобные темы стороной, и вот "сорвался" - пишу :)

Разрабатываю для веб с 2001-го. Причем сразу на Java (не путать с JavaScript) - стояла задача быстро написать для веб, а я программировал настольные приложения на C++, поэтому выбор пал на Java, как наиболее близкую по синтаксису технологию. С тех пор и пишу для веб на Java, о чем ни разу не пожалел.

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

Сторонники функционального подхода (ФП) пытаются доказать, что в небольших проектах лучше использовать ФП, а в больших - ООП. А кто-то может четко провести эту грань? Я, например, с трудом. Возможно, мне не приходилось разрабатывать "простые проекты", но, там, где необходима работа с СУБД или с потоками данных, или просто есть работа с формами, я УЖЕ буду использовать фреймворки, реализующие с помощью ООП паттерны MVC, IoC и т.п.. Потому что это УДОБНО, это ЭКОНОМИТ ВРЕМЯ, это обеспечивает МОДУЛЬНОСТЬ и ЧИТАЕМОСТЬ кода другими специалистами. Нужен УНИФИЦИРОВАННЫЙ доступ к СУБД (независимый от типа СУБД, используются ли транзакции или нет и т.п.)? Необходима УНИФИЦИРОВАННАЯ обработка форм, с выводом сообщений об ошибках и т.п.? Необходима возможность логгирования каких-то действий пользователей - сегодня в файл, а завтра в БД, а послезавтра с записью на удаленный сервер по протоколу SOAP?

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

Что делает ООП-программист? Он выносит подобную "сквозную логику" на уровень абстракции - интерфейса, и везде в коде использует эти интерфейсы (грубо говоря, определяет стиль поведения объектов). За работу с СУБД у него отвечает Интерфейс DataSource, за логгинг - интерфейс Logger, за работу форм данных - интерфейс Form. Интерфейсы определяют поведение реальных объектов, их реализующих (в терминах ФП - определяют набор функций). Т.о. каждый класс, реализующий тот или иной интерфейс, будет использовать одинаковые функции для записи в БД, проверки введенных данных и т.п., независимо от того, какая именно бизнес-логика работает внутри этих функций (запись в базу или в файл, или обращение к удаленному серверу). А дальше - больше! ООП-программист берет фреймворк, реализующий паттерн проектирования IoC (Inversion of Control - http://ru.wikipedia.org/wiki/%d0%9e%d0%b1%d1%80%d0%b0%d1%89%d0%b5%d0%bd%d0%b8%d0%b5_%d0%ba%d0%be%d0%bd%d1%82%d1%80%d0%be%d0%bb%d1%8f), и связывает всю бизнес-логику воедино посредством конфиг-файла. Что получается в итоге?

1. Программист сосредоточен ТОЛЬКО на разработке СПЕЦИФИЧНОЙ для ДАНННОГО проекта бизнес-логики.

2. Проект "собирается" воедино подобно констурктора "лего" из частей разарботанных РАЗНЫМИ разрабочиками, но говорящих друг с другом на ОДНОМ "языке" (классы реализуют стандартные интерфейсы, определенные в проекте) с помощью IoC-фреймворка.

3. В любой момент можно изменить логику проекта, написав наследника какого-нибудь класса, и заменив его для этого достаточно просто подправить КОНФИГ-файл, не внося измения в имеющийся код проекта.

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

5. За счет вынесения на уровень абстракции унифицированного функционала (а это возможно только на уровне ООП) вы сможете ПОВТОРНО использовать ОДИН и ТОТ ЖЕ функционал при СЕРЬЕЗНЫХ ИЗМЕНЕНИЯХ структуры данных.

Все это экономит время, силы и в итоге - деньги.

Готов разобрать два подхода (ФП и ООП) на готовом примере относительно "простых приложений". Например, стандартный вопрос на этом форуме - посоветуйте "движок" каталога фирм. И т.п. (естесственно, с т.з. разработки такого движка с нуля).

в java7 разрабатывают функциональные типы :)

Так в том-то и дело, что есть тренд к ОБЪЕДИНЕНИЮ возможностей ФП- и ООП-подходов, а не их противопоставлению, как это любят открыватели холиваров :)

Вы не поверите, но НЕ НУЖНО!

Эти веб-прожекты мрут быстрее чем успевают быть дописаны.

Джава-программеры не понимают когда можно остановиться. Я почему-то уверен что вы работаете не в нише массовых веб-сайтов, а в какой-нибудь корпоративной нише. С такой методикой разработки конкуренцию вам не выдержать.

Это все круто, но где-то не на этом форуме бывает.

Уже повеселило. Даже монстры разработки языков программирования пока не нашли единственного решения. В разборка, по сути умер Borland. IBM со своими реализация толком не может решить что и как делать.

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

В мире всегда существует 3 подхода. Новаторский, консервативный и разумной достаточности (когда главная цель - решение задачи). Каждый выбирает свой. Вы выбрали первый, мне более по душе - третий.

я редко соглашаюсь с netwind, но под этими словами готов подписаться.

T.R.O.N добавил 18.12.2009 в 13:20

именно потому, что он ориентирован на самое быстрое достижение результата без учета нюансов. Этим он привлекает очень много, особенно начинающих. Ведь те кто не слышал о настоящем ASP, были "шокированы" возможностью пыхи иметь серверный код внутри html текста.

дискуссии идут у всех, кроме тех языков, где давно ушли от Выбора. Хороший пример ActionScript который внедрен в FLASH. Кто пишет что-то большое - пользуют AS3, кому нужен несложный функционал, те берут AS1 где ненужно городить то, что не потребуется.

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

Уточните, плиз, что вы имеете ввиду под нишей "массовых" сайтов? Массовые сервисы, посещаемые огромным кол-вом человек, типа mail.ru и т.п.? Или массовость в вашем случае - это то, что 90% создаваемых проектов не идут дальше "сайт-визитка" с однотипным функционалом?

Ниша - разработка тематических порталов и разнообразных веб-сервисов.

:)

Везде есть программисты-экстремистсткого типа, отстаивающие исключительность их иделогических взглядов. Я к таким не одношусь :) Java-экстремисты, например, одно время предлагали выжигать каленным железом так называемое "было-кодерство" в стиле php, кричали, что "чистые" страницы jsp-это анохронизм и т.п. А мы используем быдло-кодерство со старым процедурным подходом (но не без участия ООП), например, на уровне представления (генерации итогового html/xml/etc.), потому что нам для НАШИХ задач так УДОБНЕЕ. И вто же время на уровне бекграунда (модель+бизнес-логика) - ООП, IoC и др.

Вобщем, зря я ввязался в холивар - ни к чему хорошему это не приведет, а время сжигает :)

Всем удачи! Ушел работать.

Essay добавил 18.12.2009 в 13:41

Уйти не удалось :)

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

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

Фразу "точки на i были расставлены лет 5-7 назад", следует понимать таким образом: уже тогда было ясно, что спор - бесконечен и ненужен - каждому свое. Есть ряд текущих задач, и есть ряд задач на обозримое будущее - желательно решить их с минимальными издержками. Все. У меня (и тех, кто рядом) получается это с использованием ООП-подходов лучше. Понятно, что каждый работает в собственной системе координат - стоящих перед ним задач. Если ваши задачи, вам решать легче так, как вы описали - вопросов нет. Просто есть люди, которые используют только ООП, кто-то только ФП, а кто-то совмещает разные подходы.

Я против противопоставлений :)