Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 128
в данном случае? да, что касается веба, вы угадали.
Заметте, я не сказал что ООП это ужасная штука. В старые добрые времена когда мы с ребятами писали свой 3D движек на c++, мы молились на ООП
Заметте, я не сказал что ООП это ужасная штука. В старые добрые времена когда мы с ребятами писали свой 3D движек на c++, мы молились на ООП
это не показатель :)
я вот тоже пишу на пхп (в смысле еще и на пхп), но таких вопросов как у автора топика не возникает
я вот тоже пишу на пхп (в смысле еще и на пхп), но таких вопросов как у автора топика не возникает
ООП — очень удобно.
чем? =)) тем что кроссклассовые функции и переменные приходится постоянно переобъявлять в каждом классе? =) действительно =)
Чем класс удобней процедур?
Чем класс удобней процедур?
"Эволюция, Феликс. До ООП надо дорасти ))"
© — тот "кошачий" из рекламы
© — тот "кошачий" из рекламы
17-ый век: скушай этот корешок, больной, он тебе поможет.
18-ый век: выкинь корешок, выпей вот микстурку.
19-ый век: выкинь микстурку, вот тебе укольчик.
20-ый век: выкинь укольчик, вот тебе таблеточка
21-ый век: выкинь эту таблеточку, вот тебе корешок...
Согласен с тем, что это дело вкуса. Вот только не надо говорить что "до ООП надо дорасти" в рамках веб программирования =)
18-ый век: выкинь корешок, выпей вот микстурку.
19-ый век: выкинь микстурку, вот тебе укольчик.
20-ый век: выкинь укольчик, вот тебе таблеточка
21-ый век: выкинь эту таблеточку, вот тебе корешок...
Согласен с тем, что это дело вкуса. Вот только не надо говорить что "до ООП надо дорасти" в рамках веб программирования =)
Дай корешок :)
вот как раз-таки до ООП и надо дорасти. если вы не понимаете, как это применять, то это вовсе не значит, что это плохо.
isapioff, доросший до ООП, покажи мне хоть одно свое решение на ООП с использованием всех его приемуществ. Мне как-то не очень верится, что вы сами понимаете о чем говорите =)
тем что кроссклассовые функции и переменные приходится постоянно переобъявлять в каждом классе?
Мартин Фаулер: Рефакторинг вам в руки.
Я пишу и с классами и без. И меня это не мучает.
Если вам что-то приходится что-то там массово переобьявлять, то, скорее всего, у вас неправильно спроектированно приложение. =)
До той стадии текущего проекта, до которой я дошёл, никогда не дошёл бы — пиши я его процедурно.
IMHO — "если вы написали более 500Кб кода в процедурном стиле - вы или сумасшедший или радикальный фанат".
IMHO — "если вы написали более 500Кб кода в процедурном стиле - вы или сумасшедший или радикальный фанат".
Данный пример решается так же просто практически в любом другом языке без помощи ООП, насколько я понимаю.
Объясните темному, что за "Рельсы" такие замечательные...
Объясните темному, что за "Рельсы" такие замечательные...
приведите, пожалуйста, аналог 10.hours.ago на php, очень хочется посмотреть как "так же просто" он там будет выглядеть
$time->hours(10)->ago();
Вы разные языки сравниваете. Зря.
Вы разные языки сравниваете. Зря.
руби - объект класса Fixnum (10) получает просьбу вернуть количество секунд, соответствующих количеству часов, которое он содержит, возвращенный объект класса Fixnum (36000) получает просьбу вернуть объект класса Time, содержащий значение времени, которое было 36000 секунд тому назад
пхп - ?
пс: сравниваю не я. я считаю что эти языки не сравнимы.
пхп - ?
пс: сравниваю не я. я считаю что эти языки не сравнимы.
Вспомнил ещё strtotime("-10 hours") ;)
объяснять что-то автору даже нет желания, регулярно вижу такие вопросы и бесплодные попытки ответить - объяснить это сложно поскольку у спрашивающего всегда есть желание отстоять свою точку зрения и контраргумент "а мне вот так удобнее"
контраргумент "удобней", кстати, наоборот обычно используют явные защитники ООП =)
ну.. если Вы настаиваете, все-же отвечу
при правильном подходе и достаточно больших задачах (даже выдать 2кб текста с тегами иногда требует очень большой работы до вывода :))
ООП просто помогает жить за счет повторного использования кода и лучшей его организации, на процедурах (кстати странное слово, обычно используемое паскалистами :)) большой код куда сложнее организовывать. Мне к сожалению сложно описывать все здесь с примерами, могу просто посоветовать литературу (хотя думаю Вы уже читали, просто ПОКА считаете что в вебе это не нужно)
при правильном подходе и достаточно больших задачах (даже выдать 2кб текста с тегами иногда требует очень большой работы до вывода :))
ООП просто помогает жить за счет повторного использования кода и лучшей его организации, на процедурах (кстати странное слово, обычно используемое паскалистами :)) большой код куда сложнее организовывать. Мне к сожалению сложно описывать все здесь с примерами, могу просто посоветовать литературу (хотя думаю Вы уже читали, просто ПОКА считаете что в вебе это не нужно)
Я сталкивался с разными задачами в вебе, но пока не видел ни одного проекта, где нельзя обойтись без классов в пользу грамотного, оптимизированного кода (повторяю, кода, для генерации текста).
Хотя вы правы, спорить можно бесконечно. Задачей данного топа была не зачать спор, а выплюнуть на хабр свои мысли =)
Хотя вы правы, спорить можно бесконечно. Задачей данного топа была не зачать спор, а выплюнуть на хабр свои мысли =)
ок, действительно, не будем спорить ;)
глядя на "грамотный, оптимизированный код" в стиле функционального программирования, никогда не замечали классов у себя в голове?
помойму у людей перекливает, когда они видят "ооп". русским языком написано "в вебе".
шо, есть разница?
нет разницы между головой человека и веб-разработки?
вот именно, код - он и в вебе код, сейчас и в вебе встают такие задачи в которых нужно не только пару строк вывести
а вот выражение "кода, для генерации текста" - вообще неясно что имел ввиду автор, текст генерить - не самая простая задача, особенно если он должен быть человекоподобным :)
а вот выражение "кода, для генерации текста" - вообще неясно что имел ввиду автор, текст генерить - не самая простая задача, особенно если он должен быть человекоподобным :)
примеры
На функциях проще =)
пример:
plz_generate_10mb_text();
одна строчка генерит 10 мегов текста %)
пример:
plz_generate_10mb_text();
одна строчка генерит 10 мегов текста %)
не позорьтесь, лучше промолчите.
Мне не страшно позорится, в поисках правды.
А вы, судя по всему, сидите рядом с casper в офисе, шпарите на своих рельсах и доказываете что лучше их не существует? =))
А вы, судя по всему, сидите рядом с casper в офисе, шпарите на своих рельсах и доказываете что лучше их не существует? =))
Проницательностью вас родители не обделили. Все верно, если упустить, что я понятия не имею кто casper таков, уже много лет не работаю в офисе и в настоящий момент сижу дома в одних трусах, одной рукой набирая вам ответ, а другой почесывая свои яйца.
В настоящий момент нет ничего более подходящего для веб разработки, чем rubyonrails - это утверждение, которое я смогу отстоять, если в том будет смысл. Учитывая, что ruby - pure OOP, оно противоречит вашему утверждению, которое, в рамках формальной логики, вы отстоять не сумеете.
В настоящий момент нет ничего более подходящего для веб разработки, чем rubyonrails - это утверждение, которое я смогу отстоять, если в том будет смысл. Учитывая, что ruby - pure OOP, оно противоречит вашему утверждению, которое, в рамках формальной логики, вы отстоять не сумеете.
Смотрим. Я утверждаю что для генерации 2-х килобайт html тегов не нужно ООП, что можно обойтись обычным, процедурным программированием.
ruby, по вашим словам, противоречит моему утверждению и доказывает что ООП с этой задачей справится лучше\быстрее\красивее (нужное подчеркнуть). Так получается?
ruby, по вашим словам, противоречит моему утверждению и доказывает что ООП с этой задачей справится лучше\быстрее\красивее (нужное подчеркнуть). Так получается?
Смотрим. Возможно это будет для вас сюрпризом, но генерацией хтмл тегов функции веб приложения не ограничиваются. Любое сколь угодно сложное веб приложение подразумевает построение модели данных предметной области, реализацию бизнес требований, организацию представления данных (это та часть, которой веб приложение в вашем понимании и ограничивается), написание тестов для всего этого. И без ООП тут ну никак. Вы никогда не реализуете архитектурно красивое приложение процедурным ПХП. Вы никогда не сможете добиться его стабильной работы, даже не говоря о синтаксической красоте кода.
вашими хлебальником да медку бы покушать.
конкретные примеры можно, где без ООП не обойтись?
конкретные примеры можно, где без ООП не обойтись?
между нами есть одно различие, которая делает диалог непродуктивным, сколько бы примеров я ни приводил: я понимаю, о чем говорю, вы - нет.
вы хоть один пример привели?
замечательно. Проект, где пользователи пишут каких целей они хотят достичь. Непременно огромный проект, с построением модели данных предметной области, реализации бизнес требований, организации представления данных, где без ООП ну никак не обойтись.
Пример работы НЕ ООП:
liveinternet.ru, в частности счетчики
Пример работы НЕ ООП:
liveinternet.ru, в частности счетчики
это вопрос ? :)
я-ж говорю, приводить здесь примеры преимуществ ООП не очень удобно, могу посоветовать литературу (того-же Буча http://www.ozon.ru/context/detail/id/879…)
или Вы спрашиваете про примеры задач ? или про генерацию текста ?
вот не хотел спорить, просто действительно разница между разработкой под веб и любой другой разработкой не очень существенна. раньше тоже считал что ООП в php это лишнее, но с ростом масштабов проектов это ощущение постепенно ушло (ни в коем случае не хочу обидеть, или сказать что у вас проекты менее масштабные)
я-ж говорю, приводить здесь примеры преимуществ ООП не очень удобно, могу посоветовать литературу (того-же Буча http://www.ozon.ru/context/detail/id/879…)
или Вы спрашиваете про примеры задач ? или про генерацию текста ?
вот не хотел спорить, просто действительно разница между разработкой под веб и любой другой разработкой не очень существенна. раньше тоже считал что ООП в php это лишнее, но с ростом масштабов проектов это ощущение постепенно ушло (ни в коем случае не хочу обидеть, или сказать что у вас проекты менее масштабные)
читать лениво, правда, начинался в свое время подобной литературы горы. Опять же, ООП в прикладном программировании я использовал с удовольствием.
Хороший пример ООП в вебе - fanstudio.ru, хотя на самом деле обработка фоток висит в виде демона и доступна далеко не только из веба. Т.е. мы приходим к тому что ООП выходит за рамки веба. Или я не прав?
Хороший пример ООП в вебе - fanstudio.ru, хотя на самом деле обработка фоток висит в виде демона и доступна далеко не только из веба. Т.е. мы приходим к тому что ООП выходит за рамки веба. Или я не прав?
не правы :) но подробно объяснять не буду - повторно предлагаю свернуть спор и остаться каждому при своем мнении и неотрицательной динамике кармы :)
Вы, дорогой друг, вообще на какой волне? Сейчас попробую угадать. Когда я учился в 10-ом классе и увидел, как программист в кабинете информатики таскает кнопочки, менюшечки, инпутики и комбобоксики из Toolbar на форму, затем нажимает F9 и.. о чудо! Работающая программа!
Я спросил помнится тогда: "Так это и есть хваленое объектно-ориентированное программирование"?
Он ответил: "Нет, это дельфи".
Я спросил помнится тогда: "Так это и есть хваленое объектно-ориентированное программирование"?
Он ответил: "Нет, это дельфи".
>(повторяю, кода, для генерации текста).
а я при необходимости выплюнуть что-то из ПХП пользую php_templates и очень им доволен... как вам такой подход? имхо, он отлично решает ваш вопрос - нет никакой необходимости использовать OOП/функции для форпирования ответа, достаточно просто передать данные отдельному, оптимизированному, и очень быстрому модулю :)
а я при необходимости выплюнуть что-то из ПХП пользую php_templates и очень им доволен... как вам такой подход? имхо, он отлично решает ваш вопрос - нет никакой необходимости использовать OOП/функции для форпирования ответа, достаточно просто передать данные отдельному, оптимизированному, и очень быстрому модулю :)
Инкапсуляция.
Все еще кипятите? Тогда мы идем к вам :)
Если серьезно, то все зависит от того что вы хотите получить и что у вас за задача. Но если у вас большой проект с сложным взаимодействием, то ООП довольно таки полезно. К тому же советую попробовать какие либо ООП фреймворки. Написать с их использованием, а затем с без их использования и использования ООП. Потом сравнить затраченные усилия объем кода и скорость работы. Еще так же хочу напомнить, что в корпоративном секторе для веба часто используется java. Ну и про модель того как java сопрягается с вебом, я считаю одной из самых удачных.
Если серьезно, то все зависит от того что вы хотите получить и что у вас за задача. Но если у вас большой проект с сложным взаимодействием, то ООП довольно таки полезно. К тому же советую попробовать какие либо ООП фреймворки. Написать с их использованием, а затем с без их использования и использования ООП. Потом сравнить затраченные усилия объем кода и скорость работы. Еще так же хочу напомнить, что в корпоративном секторе для веба часто используется java. Ну и про модель того как java сопрягается с вебом, я считаю одной из самых удачных.
я не спорю по поводу быстроты разработки. Мне жаль сервера =)
Тогда вам стоит писать на ассемблере. К тому же как вам такой поворот как quercus? Это реализация PHP на Java. Приведу цитату оттуда:
Вот вам и медленнее :)
Performance - simply faster
* Quercus outperforms straight mod_php by about 4x for MediaWiki and Drupal.
* PHP developers can use Java tools like profilers to get in-depth information about the PHP program performance.
Вот вам и медленнее :)
Погодите погодите, ява компилируется. Если мы компилируем php, каким бы он ООП небыл, на выходе мы получим тоже быстрое приложение. Но никак не быстрее процедурного.
>но никак не быстрее
мне вот интересно, а на сколько вызов функции отличается от вызова собственного метода на этапе исполнения?..
мне вот интересно, а на сколько вызов функции отличается от вызова собственного метода на этапе исполнения?..
Объявление объекта и описывая его дефолтовыми значениями от дозвона до фукнкции? двумя действиями точно =)
пардон, вы ничего не путаете?
предполагается что объект уже создан, так-же как у вас в процедурном стиле объявляются переменные и объявляются функции и т.д...
а дальше в чем раница мужду $this->do_smthng(); и просто do_smthng(); !?
предполагается что объект уже создан, так-же как у вас в процедурном стиле объявляются переменные и объявляются функции и т.д...
а дальше в чем раница мужду $this->do_smthng(); и просто do_smthng(); !?
но ведь перед тем как обращаться к объектку его нужно создать, не так ли?
перед тем как вызвать функцию вы тоже что-то создаете.
я лично предполагаю что создание контента уходит гораздо дальше обычного time("Y-m-d H:i:s");
сответвенно временем на создание можно преенебречь на фоне остальных временных затрат (например на подключение к базе, сложные выборки из нее, когда сервре гудит и парится над 100G данных, и прочие дела ;) )
да и вообще, хватит передергиват, я задал вопрос о ВЫЗОВЕ, а не про создание а потом вызов.
я лично предполагаю что создание контента уходит гораздо дальше обычного time("Y-m-d H:i:s");
сответвенно временем на создание можно преенебречь на фоне остальных временных затрат (например на подключение к базе, сложные выборки из нее, когда сервре гудит и парится над 100G данных, и прочие дела ;) )
да и вообще, хватит передергиват, я задал вопрос о ВЫЗОВЕ, а не про создание а потом вызов.
как то сумбурно получилось. подправлю:
перед тем как вызвать функцию вы тоже что-то создаете (имеется в виду объявляете).
я лично предполагаю чтосоздание формирование контента уходит гораздо дальше обычного time("Y-m-d H:i:s");
сответвенно временем насоздание обявление и инициализацию объектов можно преенебречь на фоне остальных временных затрат (например на подключение к базе, сложные выборки из нее, когда сервре гудит и парится над 100G данных, и прочие дела ;) )
да и вообще, хватит передергиват, я задал вопрос о ВЫЗОВЕ, а не просоздание инициализацию а потом вызов.
перед тем как вызвать функцию вы тоже что-то создаете (имеется в виду объявляете).
я лично предполагаю что
сответвенно временем на
да и вообще, хватит передергиват, я задал вопрос о ВЫЗОВЕ, а не про
обращаясь к функции объекта ты все равно сначала обращаешься к объекту и только потом к его функции.
к собственному методу?
никак не через ссылку в памяти, нет?
никак не через ссылку в памяти, нет?
вдогонку.
создавая тему Вы ни разу не упомянули про PHP.
а если обстоятельства вынуждают писать меня фронтэнд на java? каким простите боком я туда всуну процедурный подход!?
кстати, напомню, Java штука НЕ медленная. ради чего я должен ставить еще один веб-сервер, думать как на одном ip подружить томкат с апачем, мудохаться в AJP? только для того чтобы не использовать OOP при формировании text/html ответов клиенту !?
смешно, право слово.
создавая тему Вы ни разу не упомянули про PHP.
а если обстоятельства вынуждают писать меня фронтэнд на java? каким простите боком я туда всуну процедурный подход!?
кстати, напомню, Java штука НЕ медленная. ради чего я должен ставить еще один веб-сервер, думать как на одном ip подружить томкат с апачем, мудохаться в AJP? только для того чтобы не использовать OOP при формировании text/html ответов клиенту !?
смешно, право слово.
Брр что-то вы странное говорите. Все гараздо проще связывается. Посмотрите тот же resin и используемый модуль для связки с apache. Опять же можно использовать один нативный resin. Статику он тоже неплохо отдает.
1. я утрирую :)
2. "можно использовать" говорит о том, что мне нужно еще что-то делать, только для того чтобы... в общем переворачивает все с ног на голову. когда неоходимость отдавать кому-то что-то в виде HTMLя вляется побочной, а скорость именно этой побочности не критичной... напрягаться только из-за нелюбви к ООП ... увольте :)
3. с таким-же фанатизмом можно заявлять что XSLT это тормоз и использовать его нельзя. но ведь используют, и не тормозит при грамотном подходе :)
просто всему свое место и всему есть свои области применения. если не быть фанатиком и использовать те или иныее методолгии/архитектуры/подходы там где они позволяют выиграть - все будет чудесно. но фанатично кричать это-рулез, а вот-то - сакс...
2. "можно использовать" говорит о том, что мне нужно еще что-то делать, только для того чтобы... в общем переворачивает все с ног на голову. когда неоходимость отдавать кому-то что-то в виде HTMLя вляется побочной, а скорость именно этой побочности не критичной... напрягаться только из-за нелюбви к ООП ... увольте :)
3. с таким-же фанатизмом можно заявлять что XSLT это тормоз и использовать его нельзя. но ведь используют, и не тормозит при грамотном подходе :)
просто всему свое место и всему есть свои области применения. если не быть фанатиком и использовать те или иныее методолгии/архитектуры/подходы там где они позволяют выиграть - все будет чудесно. но фанатично кричать это-рулез, а вот-то - сакс...
А я где-то кричу это сакс это рулез? :) Я использую процедурный подход там где он себя оправдывает.
речь идет о топикстартере ;)
начиная отсюда Вы высказывали только дельные мысли :)
начиная отсюда Вы высказывали только дельные мысли :)
упс. забыл сказать спасибо за Resin.
на самом деле пример был высосан из пальца, и особой необходжимости пока не возникало, но в мемориз добавил - вдруг пригодится :)
(хотя при беглом осмотре так и не понял, чем он лучше tomcat+mod_jk кроме , т.к. судя по обзорам томкат как сервлет-контейнер пошустрее работает...)
на самом деле пример был высосан из пальца, и особой необходжимости пока не возникало, но в мемориз добавил - вдруг пригодится :)
(хотя при беглом осмотре так и не понял, чем он лучше tomcat+mod_jk кроме , т.к. судя по обзорам томкат как сервлет-контейнер пошустрее работает...)
Во первых удобнее тем, что ничего настраивать кроме собственно какой узел и какую директорию цепляем не надо. mod_caucho просто работает в отличии от mod_jk. Во вторых у resin меньше настроек и разобраться в них гараздо проще чем в настройках tomcat. В третьих resin жрет несколько поменьше памяти и работает быстрее tomcat :) Это я вам как человек использовавший этих два решения говорю. Если же если вы еще возмете resin pro с поддержкой openssl и что самое главное кешинга, то будет еще быстрее :)
Когда эта штука только вышла, то был еще и тест который сравнивал это решение с php+APC прирост у них все равно получался. Под quercus работало раза в два быстрее :)
у вас есть достаточно сложные проекты написанные в процедурном и ОО-стилях
очень интересно было бы посмотреть на время разработки каждого из вариантов и на производительность оных
очень интересно было бы посмотреть на время разработки каждого из вариантов и на производительность оных
Сервер, конечно жаль. Но в том самом ООП часто применяют кэши. Вот на них и выезжают.
А если подключить сюда ещё и какой-нибудь memcached…
А если подключить сюда ещё и какой-нибудь memcached…
очень часто затраты на тюнинг кода превышают стоимость аппаратного апгрейда. поэтому прежде чем жалеть сервер стоит подсчитать, не дешевле-ли его заменить :)
И вообще, есть более забавное слово - АОП ;)
Интересная концепция, но я ее пока не переварил. Если есть ссылки на литературу, поделитесь.
http://ru.wikipedia.org/wiki/Аспект-орие…
И там в конце есть пара ссылок.
http://ru.wikibooks.org/wiki/Аспектно-ор…
Тоже занимательно.
Сам я обычно нахожу штук 20 статей - и ем. Сначала мутит, а потом ничего так, переваривается ;)
Ну и поисковики в помощь ;)
И там в конце есть пара ссылок.
http://ru.wikibooks.org/wiki/Аспектно-ор…
Тоже занимательно.
Сам я обычно нахожу штук 20 статей - и ем. Сначала мутит, а потом ничего так, переваривается ;)
Ну и поисковики в помощь ;)
аспектно-ориентированное программирование?
/* offtopic
Надо же, тут и Трин тусуется =)
*/
IMHO: если человек писал до веба в C++ или Java и активно использовал ООП, то ему проще использовать ООП в своих проектах для веба. Если же человек новичок в веб-программировании и не имел опыта программирования серьезного до этого в прикладных языках, то он нескоро поймет, зачем тут вообще ООП нужно =)
Немного сумбурно, но вот такое вот имхо. :)
Надо же, тут и Трин тусуется =)
*/
IMHO: если человек писал до веба в C++ или Java и активно использовал ООП, то ему проще использовать ООП в своих проектах для веба. Если же человек новичок в веб-программировании и не имел опыта программирования серьезного до этого в прикладных языках, то он нескоро поймет, зачем тут вообще ООП нужно =)
Немного сумбурно, но вот такое вот имхо. :)
Суть ООП в итоге не в том чтобы облегчить жизнь кодера, а в том чтобы облегчить проектирование объемных приложений. Как минимум странно утверждать что ООП лучше или хуже структурного. Это различные концепции, и задействованы они в различных областях. Но всеже при проектировании объемного приложения сущности которого, в принципе, невозможно удержать в голове, единственный выход разделить систему на ряд более мелких объектов и рассматривать их как самодостаточные системы (естественно учитывая последующее их взаимодействие), а уже потом из них собирать более сложную систему.
В итоге ООП стал необходимым шагом в процессе усложнения разрабатываемого ПО, и если вам еще не приходилось решать достаточно масштабные задачи, чтобы не запутаться в дебрях функций и переменных - это не повод для скептических суждений.
В итоге ООП стал необходимым шагом в процессе усложнения разрабатываемого ПО, и если вам еще не приходилось решать достаточно масштабные задачи, чтобы не запутаться в дебрях функций и переменных - это не повод для скептических суждений.
ля ля - ля ля - ля ля, а я сошла с ума...
Еще раз читаем топик:
"спорил о смысле ООП в вебе"
Взвешивая все плюсы и минусы веб-программирования, можно легко прийти к выводу что ООП тут не настолько нужен, насколько он будет тормозить процесс генерации страниц.
Web приложения отличаются достаточно простой логикой. Зачастую это всего лишь интерфейс к софту на сервере или к базе. И основная оссобенность веба - все действия происходят на сервере, а не на машине пользователя, отсюда мы имеем потребность в быстром коде с точки зрения исполнения его на сервере.
Еще раз читаем топик:
"спорил о смысле ООП в вебе"
Взвешивая все плюсы и минусы веб-программирования, можно легко прийти к выводу что ООП тут не настолько нужен, насколько он будет тормозить процесс генерации страниц.
Web приложения отличаются достаточно простой логикой. Зачастую это всего лишь интерфейс к софту на сервере или к базе. И основная оссобенность веба - все действия происходят на сервере, а не на машине пользователя, отсюда мы имеем потребность в быстром коде с точки зрения исполнения его на сервере.
Я повторюсь, с вашего позволения.
"Если вам еще не приходилось решать достаточно масштабные задачи, чтобы не запутаться в дебрях функций и переменных - это не повод для скептических суждений."
"Если вам еще не приходилось решать достаточно масштабные задачи, чтобы не запутаться в дебрях функций и переменных - это не повод для скептических суждений."
я тоже:
"Web приложения отличаются достаточно простой логикой. Зачастую это всего лишь интерфейс к софту на сервере или к базе."
"Web приложения отличаются достаточно простой логикой. Зачастую это всего лишь интерфейс к софту на сервере или к базе."
ИМО, спорить бесполезно.
вы ошибаетесь. для домашних страниц и форумов - можно и без ООП. для серьезных приложений - не получится. на текущем проекте (анализ финансовых рисков) у нас 2444 класса. в каждом, скажем, 7 методов. получается ~17000 методов. делим это число на два, так как многие из этих методов - просто get/set - ~8500 методов. это будут Ваши функции в процедурных языках.
я, например, не чувствую в себе сил поднять проект на процедурном языке, в котором будет 8500 процедур...
я, например, не чувствую в себе сил поднять проект на процедурном языке, в котором будет 8500 процедур...
вы, очевидно, не писали серьезные web-приложения, которые используются для автоматизации бизнесс-процессов.
Если не хватает авторитета пользователей Хабра буду использовать авторитет компании создавшей PHP. Итак Zend Framework написан на чистом ООП. И думаю компания Zend принимала это решение не просто так.
Zend писали фреймворк не потому что у них "лежит душа", а потому что надо. А, как выяснилось, 98% пользвоателей php считают что ООП - это классы, а классы это такая "удобная штука иерархического хранения функций". Соответственно им "надо" годнить 98% пользователей, фрейморк писан на классах.
Да и вообще, тут насколько я помню, лиь трое сказали правильную мысль, что суть то не меняется, используешь ты ООП или нет. Остальные усиленно доказывают что ООП это круто и ничего больше не надо. А на самом деле эти "остальные" считают что ООП, это $fucking->shit(); и ничего большего.
В общем спор помойму зашел в тупик, смысла спорить дальше я не вижу. Одни доказывают что ООП это удобная работа со временем, другие говорят что их проект состоит из 2500 классов (скажи ID Software что в твоем проекте 2500 объектов, описанных с помощью ООП, они пойдут в сторонку нервно курить), третьи говорят мол "раз все юзают ООП, значит это точно круто".
Да и вообще, тут насколько я помню, лиь трое сказали правильную мысль, что суть то не меняется, используешь ты ООП или нет. Остальные усиленно доказывают что ООП это круто и ничего больше не надо. А на самом деле эти "остальные" считают что ООП, это $fucking->shit(); и ничего большего.
В общем спор помойму зашел в тупик, смысла спорить дальше я не вижу. Одни доказывают что ООП это удобная работа со временем, другие говорят что их проект состоит из 2500 классов (скажи ID Software что в твоем проекте 2500 объектов, описанных с помощью ООП, они пойдут в сторонку нервно курить), третьи говорят мол "раз все юзают ООП, значит это точно круто".
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мысли вслух. ООП