Комментарии 127
habracut забыли! :-)
но вы не учитываете нескольких ньюансов. РНР работает по "сессионной" модели, то есть скрипт, по большому счету (не учитываем сейчас кешеров и т.п.) каждый раз в ответ на запрос обрабатывает код страницы. Теперь смотрим - если мне нужно изменить какие-то данные в анкете пользователя, то для этого нужно создать обьекты, изменить в них данные, записать... в зависимости от архитектуры конечно. Но само действие это есть атомарным и простым - исходя из того, что соединение с базой и некоторые переменные окружения являются статичными между всеми скриптами, эта операция не требует по своей природе никаких обьектов, а только выполнения одного запроса (ну и некоторых сервисных действий вроде проверки формата и т.п.). В вот монстры вроде ZendFramework на каждое действие вынуждены поднимать иерархии с десятков классов ради вызова одного-двух небольших методов. Это я к тому веду, что думать нужно прежде. когда накладные расходы на ООП в каждом случае больше, чем выгода - он малоприемлем.
Сейчас работа человека дороже оборудования и часто выгоднее пожертвовать скоростью работы приложения ради скорости разработки и удобства поддержки.
так вы противоречите сами себе, поскольку, исходя из этого процедурный подход выигрывает, так как человек, пишущий на ООП, стоит дороже, и чем лучше он, тем дороже.
Кроме этого, всплывают вопросы надежность и много других, которые только в последние время начали подниматься, так как раньше просто не было больших реально ООП систем и опыта их жизненного цикла.
Кроме этого, всплывают вопросы надежность и много других, которые только в последние время начали подниматься, так как раньше просто не было больших реально ООП систем и опыта их жизненного цикла.
"так как человек, пишущий на ООП стоит дороже"
- откуда упали ? Основы ООП изучается за день, а реальное понимание приходит за месяц активного использования. Если человек программер (не в кавычках), то он ооп освоит на раз два.
"Кроме этого, всплывают вопросы надежность и много других, которые только в последние время начали подниматься, так как раньше просто не было больших реально ООП систем и опыта их жизненного цикла."
- с добрым утром, ООП используют десятки лет. Даже больше скажу, когда много, много лет назад небыло ООП'а, как вы его понимаете, люди писали процедурно в стиле ооп. Реально больших проектов, это какие ? Windows, Linux, MacOS ??? - так они все по большей часте написаны много много лет назад с использованием ооп.
- откуда упали ? Основы ООП изучается за день, а реальное понимание приходит за месяц активного использования. Если человек программер (не в кавычках), то он ооп освоит на раз два.
"Кроме этого, всплывают вопросы надежность и много других, которые только в последние время начали подниматься, так как раньше просто не было больших реально ООП систем и опыта их жизненного цикла."
- с добрым утром, ООП используют десятки лет. Даже больше скажу, когда много, много лет назад небыло ООП'а, как вы его понимаете, люди писали процедурно в стиле ооп. Реально больших проектов, это какие ? Windows, Linux, MacOS ??? - так они все по большей часте написаны много много лет назад с использованием ооп.
win32API тоже ООП? кстати, всего с 80 годов, если смотреть на смалталк, но на нем я не знаю, писали ли реально большие системы.
не превращаем этот тренд в спор про ООП вообще. В вебе, в РНР и в достаточно большом классе приложений ООП не является панацеей и может быть заменено процедурным подходом вполне. тем более, как заметили ниже, РНР предлагает мультипарадигму, потому не ограничивайте себя.
Кстати, если ООП панацея, то почему дальше развивают и аспектно-ориентированное программирование появилось?
не превращаем этот тренд в спор про ООП вообще. В вебе, в РНР и в достаточно большом классе приложений ООП не является панацеей и может быть заменено процедурным подходом вполне. тем более, как заметили ниже, РНР предлагает мультипарадигму, потому не ограничивайте себя.
Кстати, если ООП панацея, то почему дальше развивают и аспектно-ориентированное программирование появилось?
Всего с 80x - Разве это мало ? Двадцать слишнем лет. А вы говорите что ооп совсем молод. Интернету так таковому меньше лет.
"Кстати, если ООП панацея," - вы не совсем верно протрактовали мой ответ. Я лишь опровергаю домыслы, что ооп совсем молод, он дороже, отстуствие больших проектов и так далее.
"Кстати, если ООП панацея," - вы не совсем верно протрактовали мой ответ. Я лишь опровергаю домыслы, что ооп совсем молод, он дороже, отстуствие больших проектов и так далее.
да я не отрицал :) просто если мерять вообще, а не инетом в частности, то и 20 лет это мало.. мосты, автомобили, железная дорога - вот когда сотни лет будут, тогда :)
а так да, в большинстве случаев он дороже, при неверном проектировании он намного дороже, требудет бОльшей квалификации для архитектуры.
а так да, в большинстве случаев он дороже, при неверном проектировании он намного дороже, требудет бОльшей квалификации для архитектуры.
а к чему тут мосты и автомобили?
вы от начала распространения программирования вообще (в понимании современных компьютеров) считайте. будет более чем достаточно.
вы от начала распространения программирования вообще (в понимании современных компьютеров) считайте. будет более чем достаточно.
разговор о ИТ. при чем тут мосты.
еще с десяток лет назад, люди сидели на модемах с 56к каналы были узкими, а сейчас гигабиты - обыденное дело.
20 лет назад бой был на мегабайты на винчестерах, а сейчас мысли в стиле "а не прикупить бы пару винтов по терабайту, а то порно некуда складировать".
еще с десяток лет назад, люди сидели на модемах с 56к каналы были узкими, а сейчас гигабиты - обыденное дело.
20 лет назад бой был на мегабайты на винчестерах, а сейчас мысли в стиле "а не прикупить бы пару винтов по терабайту, а то порно некуда складировать".
В принципе win32API можно назвать проООП.
когда передаёте функции указатель на окно или какую структуру, то это и есть ссылка на объект.
В принципе ООП это те же функции, первый параметр которой ссылка на объект. т.е. в простых случаях
$obj->proc($a,$b)
это то же что и
proc($obj,$a,$b)
Понимаю, можно поспорить, но фактически в результате компиляции так и происходит. Кто дебагил скомпилированный ООП код меня думаю поддержит.
когда передаёте функции указатель на окно или какую структуру, то это и есть ссылка на объект.
В принципе ООП это те же функции, первый параметр которой ссылка на объект. т.е. в простых случаях
$obj->proc($a,$b)
это то же что и
proc($obj,$a,$b)
Понимаю, можно поспорить, но фактически в результате компиляции так и происходит. Кто дебагил скомпилированный ООП код меня думаю поддержит.
Поддержит :)
Куда дели полиморфизм, наследование и т.д.? Это не есть ООП, это есть "стиль ООП", в котором сами принципы ООП реализовать невозможно.
вынужден заметить, что я уже насмотрелся на изучивших основы ооп за день и все понявших за месяц.
в пхп по перечисленным Вашим оппонентам причинам, область применения ооп довольно ограничена.... честно говоря, как раз тем уровнем, который можно понять за месяц :)
ps: только без войн! пхп - замечательный для своего широчайшего круга задач язык.
в пхп по перечисленным Вашим оппонентам причинам, область применения ооп довольно ограничена.... честно говоря, как раз тем уровнем, который можно понять за месяц :)
ps: только без войн! пхп - замечательный для своего широчайшего круга задач язык.
>- откуда упали ? Основы ООП изучается за день, а реальное понимание приходит за месяц активного использования. Если человек программер (не в кавычках), то он ооп освоит на раз два.
Использовать объекты вместо процедур - пожалуйста, но это не избавит его от говнокода в ООП. Реальное понимание и грамотное использование паттернов приходит с годами разработки
Использовать объекты вместо процедур - пожалуйста, но это не избавит его от говнокода в ООП. Реальное понимание и грамотное использование паттернов приходит с годами разработки
это имеет отношение только к оффлайновым приложениям, так, например, изменился подход к созданию компьютерных игр. с сетевыми все сложнее - жертвование скоростью ради удобства программиста может превратить сайт в многоминутного тормоза, из-за невозможности быстрого подключения к которому, будут уходить пользователи.
+1 в карму, сразу :)
Хотя этот ответ и не соответствует мнению тутошнего большинства (посмотрите мою карму :)) ).
Хотя этот ответ и не соответствует мнению тутошнего большинства (посмотрите мою карму :)) ).
Мда. Сам хабр - тоже против. Я не могу повысить Вам карму, sorry :(
"накладные расходы на ООП" )) Да сколько же уже можно поднимать тему тормознутости ооп в php? Кэширование страниц и опкода и будет вам счастье. А вот скорость разработки и удобство поддержки решает.
Ajax - слыхали? Знакомы?
это при чем? вполне, если посмотрите на сайт в моем профайле. и что из этого?
Но само действие это есть атомарным и простым - исходя из того, что соединение с базой и некоторые переменные окружения являются статичными между всеми скриптами, эта операция не требует по своей природе никаких обьектов, а только выполнения одного запроса
Сделайте её аяксовой. Как повышение/понижение кармы тут. Или рейтингу топика. Или как минус мне.
Сделайте её аяксовой. Как повышение/понижение кармы тут. Или рейтингу топика. Или как минус мне.
Весенние обострение ?
вот проверил статистику у себя на данный момент:
3 демона на PHP 5.1 работают уже больше неделе на публичном хостинге. Используют событийную модель для взаимодействий между собой.
в случае смерти демона, он автоматически поднимается (за неделю ни одного случая)
Плюс в сравнении с Java, например:
нет утечек памяти и сложно накасячить так чтоб были
проще писать многие задачи WEB
Минусы:
много доп работы для обеспечения стабильности.
Хотел сказать что PHP уже вырос и решает далеко не только "ссесионные" задачи
3 демона на PHP 5.1 работают уже больше неделе на публичном хостинге. Используют событийную модель для взаимодействий между собой.
в случае смерти демона, он автоматически поднимается (за неделю ни одного случая)
Плюс в сравнении с Java, например:
нет утечек памяти и сложно накасячить так чтоб были
проще писать многие задачи WEB
Минусы:
много доп работы для обеспечения стабильности.
Хотел сказать что PHP уже вырос и решает далеко не только "ссесионные" задачи
Топик и заголовок как то невяжутса. Заголовок топика "ООП или процедурный подход", а статья в стиле "Почему ООП лучше процедурного подхода".
>ООП обучает любой язык программирования более хорошему программному коду и используется, для получения более высокой производительности и написания больших проектов
Здесь наверное было "высокой производительности при написании больших проектов"
А вообще-то, пример ООП неудачный.
Здесь наверное было "высокой производительности при написании больших проектов"
А вообще-то, пример ООП неудачный.
НЛО прилетело и опубликовало эту надпись здесь
Я как чел перешедший давно с процедурного на ООП, примером совершенно не восхищен.
Страшные слова, типа рефакторинг, готовность, модифицируемость, безопасность, контроллепригодность и практичность и т.п. обычному процедурщику ничего не даст.
Пока его код не перевалит за 20-30 тысяч строк кода, он будет (так же как и я раньше) всеми возможными способами говорить что это сложно, страшно, медленно и неудобно.
До ООП надо дорасти! (И там новые этапы роста: после освоения классов и объектов, приходит понимание интерфейсов, а после паттерны).
Для процедурщиков: Как бы вы хорошо не писали, рано или поздно перейдети на ООП. Оно необходимо. Если бы ООП было ЗЛОМ, его бы уже давно загнобили.
Страшные слова, типа рефакторинг, готовность, модифицируемость, безопасность, контроллепригодность и практичность и т.п. обычному процедурщику ничего не даст.
Пока его код не перевалит за 20-30 тысяч строк кода, он будет (так же как и я раньше) всеми возможными способами говорить что это сложно, страшно, медленно и неудобно.
До ООП надо дорасти! (И там новые этапы роста: после освоения классов и объектов, приходит понимание интерфейсов, а после паттерны).
Для процедурщиков: Как бы вы хорошо не писали, рано или поздно перейдети на ООП. Оно необходимо. Если бы ООП было ЗЛОМ, его бы уже давно загнобили.
А вообще АВТОР - МОЛОДЕЦ. Пиши ИСЧО.
НЛО прилетело и опубликовало эту надпись здесь
если слова рефакторинг, готовность, модифицируемость, безопасность, контроллепригодность и практичность программисту ничего не говорят, то он плохой или пока неопытный программист =)
Тут некоторые пишут, что ООП понимается за день и осваивается за месяц.
ООП - это в первую очередь образ мышления, и опытность в нём приходит, наверное, за год. Сначала вы пишете процедурным подходом, используя классы как модули (или пространства имён), потом приходит понимание того, что такое делегирование, потом приходят на помощь паттерны проектирования, потом понимание того, что ты ничего так и не понял, и так по кругу.
Код раз за разом становится проще, но даже такие программисты, как Фаулер, осваивали ООП с большим трудом.
Пример, который приведён в статье неиллюстративен, а сама статья напугает как процедурщика, так и объектно-ориентированного программиста.
Чтобы научиться ООП, необходимо много свободного времени и какой-то проект, который можно много раз переписывать, т.е. скорее всего некоммерческий продукт или продукт "для своих". Потому что только практика может показать, что же на самом деле скрывается за одними и теми же словами.
ООП - это в первую очередь образ мышления, и опытность в нём приходит, наверное, за год. Сначала вы пишете процедурным подходом, используя классы как модули (или пространства имён), потом приходит понимание того, что такое делегирование, потом приходят на помощь паттерны проектирования, потом понимание того, что ты ничего так и не понял, и так по кругу.
Код раз за разом становится проще, но даже такие программисты, как Фаулер, осваивали ООП с большим трудом.
Пример, который приведён в статье неиллюстративен, а сама статья напугает как процедурщика, так и объектно-ориентированного программиста.
Чтобы научиться ООП, необходимо много свободного времени и какой-то проект, который можно много раз переписывать, т.е. скорее всего некоммерческий продукт или продукт "для своих". Потому что только практика может показать, что же на самом деле скрывается за одними и теми же словами.
c> До ООП надо дорасти!
Согласен. На прошлой работе рефакторил одну опенсорсную систему тест-менеджмента, RTH называется, где воочию можно наблюдать продедурный ад, и прозрел :)
На самом деле, ООП-код действительно более читабелен, но к нему надо привыкнуть. При прочих равных на сам кодинг уходит больше времени, чем это было бы при процедурном подходе. Однако, когда встаёт вопрос об управляемости, выбор однозначно стоит сделать в пользу ООП.
П. С. Кстати говоря, я в большинстве своих проектов совмещал ООП и процедурный подход (естественно, там, где оно себя оправдывало).
Согласен. На прошлой работе рефакторил одну опенсорсную систему тест-менеджмента, RTH называется, где воочию можно наблюдать продедурный ад, и прозрел :)
На самом деле, ООП-код действительно более читабелен, но к нему надо привыкнуть. При прочих равных на сам кодинг уходит больше времени, чем это было бы при процедурном подходе. Однако, когда встаёт вопрос об управляемости, выбор однозначно стоит сделать в пользу ООП.
П. С. Кстати говоря, я в большинстве своих проектов совмещал ООП и процедурный подход (естественно, там, где оно себя оправдывало).
НЛО прилетело и опубликовало эту надпись здесь
Потому что:
* каждый называет функции и переменные, классы как захочет
* каждый видит проблемы и задачи по-своему
* у каждого разные понятия представления физической модели (эт я про ООП)
этого уже достаточно чтобы плодить разные фреймворки
ну а чего плохого что куча фреймворков???
* каждый называет функции и переменные, классы как захочет
* каждый видит проблемы и задачи по-своему
* у каждого разные понятия представления физической модели (эт я про ООП)
этого уже достаточно чтобы плодить разные фреймворки
ну а чего плохого что куча фреймворков???
НЛО прилетело и опубликовало эту надпись здесь
Это был первый топик, поэтому в дальнейших я учту все замечания и постараюсь сделать его более качественным, лично мне понравилась книга Object Oriented Programming with PHP5, так как из всех, что я читал по РНР в ней более толково объясняется суть ООП. так что если не против то я буду продолжать вылаживать переводы.
Изучение PHP абсолютно не тяжёлое занятие, особенно если вы хорошо знакомы с синтаксисом Java...
----------------------------------------------------
Если вы знакомы с синтаксисом Java, то изучение PHP есть крайне тяжёлая психологическая задача. Тяжелее пожалуй будет только изучение Бейсика. :)
Впрочем... убеждать в 21 веке людей в достоинствах ООП подхода тож задача не из лёгких. Воистину инерция человеческого мозга безгранична. :)
----------------------------------------------------
Если вы знакомы с синтаксисом Java, то изучение PHP есть крайне тяжёлая психологическая задача. Тяжелее пожалуй будет только изучение Бейсика. :)
Впрочем... убеждать в 21 веке людей в достоинствах ООП подхода тож задача не из лёгких. Воистину инерция человеческого мозга безгранична. :)
Преимущества эт каеш хорошо, но вы забыли про недостатки ООП подхода.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я согласен и с вами, и с тем что топик следовало бы назвать иначе. Но считаю что статья будет полезна тем кто решается переходить ли на ООП или нет, или для тех кто не понимает преимуществ ООП.
Согласен. По PHP вообще, несмотря на его доступность огромному количеству людей, очень мало толковых книг. В рунете так вообще очень мало инфы, причём вся инфа сосредоточена на трёх форумах - пхпклуб, котеров, в меньшей степени - икспоинт. (Буду благодарен за ссылки на хорошие ресурсы по PHP).
Лучшим ресурсом остаётся официальная дока с пользовательскими комментариями, но раздел про ООП там имхо бестолковый.
зы - я долгое время кодил на PHP и слабо понимал концепцию ООП как таковую. В лучшем случае мои потуги сводились к классам-обёрткам для функций. Всё изменилось тогда, когда жизнь подбросила мне работу с Java и я более-менее втянулся в процесс разработки сайта, написанного целиком на Java (не без предварительного обучения, конечно). Так вот меня как будто осенило - я осознал основные преимущества ООП, про которые пишут почти во всех статьях про этот подход (раньше я тоже читал подобные статьи в большом количестве, но в упор их не видел).
ЗЗЫ - теперь я тоже стараюсь писать грамотный код на PHP и надо сказать, что PHP очень и очень слаб в плане ООП (именно в этом я вижу причину того, что дойти до преимуществ подхода, программируя на PHP очень непросто). Писать легко управляемые и расширяемые проекты, конечно, можно, но оно достигается довольно большим количеством искусственных хаков и соглашений.
Лучшим ресурсом остаётся официальная дока с пользовательскими комментариями, но раздел про ООП там имхо бестолковый.
зы - я долгое время кодил на PHP и слабо понимал концепцию ООП как таковую. В лучшем случае мои потуги сводились к классам-обёрткам для функций. Всё изменилось тогда, когда жизнь подбросила мне работу с Java и я более-менее втянулся в процесс разработки сайта, написанного целиком на Java (не без предварительного обучения, конечно). Так вот меня как будто осенило - я осознал основные преимущества ООП, про которые пишут почти во всех статьях про этот подход (раньше я тоже читал подобные статьи в большом количестве, но в упор их не видел).
ЗЗЫ - теперь я тоже стараюсь писать грамотный код на PHP и надо сказать, что PHP очень и очень слаб в плане ООП (именно в этом я вижу причину того, что дойти до преимуществ подхода, программируя на PHP очень непросто). Писать легко управляемые и расширяемые проекты, конечно, можно, но оно достигается довольно большим количеством искусственных хаков и соглашений.
Каждый кодер PHP со временем для себя поймет, и рано или поздно придет и к ООП, и к фреймворкам, таким как codeigniter. А потом наверно и вовсе уйдет на RoR. Во всяком случае я вижу правильную эволюцию именно так :) сейчас я на пути от codeigniter'а к RoR :)
Я так не считаю. Я вот пришёл в PHP из JAVA(жизнь заставила!) и считаю что очень неплохо понимаю ООП. Я сразу же оценил преимущества процедурного программирования на PHP гораздо легче и быстрей писать простенькую сервер логику именно в процедурном стиле причом совершенно так же можно её переиспользовать. ООП хорош для больших проектов требующих проектирование и планирование. Сколько больших проектов вы делаете в год, а сколько маленьких? Вот собственно и ответ.
Если писать действительно хороший код. То один большой проект вам даст очень много хорошо написанных ре-юзабельных классов. Писать маленькие потом будет одно удовольствие - процесс похож на игру в конструктор, вся бизнес логика уже написана - остаётся только переписать контроллер под маленький проект, выкинув всё ненужное и дописав недостающие классы (грамотное написание которых, кстати, пополняют вашу библиотеку реюзабельных модулей).
Ну я до PHP изучал C++Builder, с ООП там тоже все ок :) О простой логике никто и не спорит - если исходник не превышает, ну скажем, двух-трех экранов, то ООП тут ни к чему. Я вот маленькие проекты вообще не делаю - делаю достаточно большие. И сейчас занимаюсь переписыванием на ООП того что делал до, потому что сам перестал понимать свои исходники с функциями, а дорабатывать эти вещи нужно постоянно. При чем скоро этим будут заниматься еще люди, которые навряд ли поймут мои исходники если я их сам не понимаю :)
Я вообще воспринимаю процедурный подход как ООП с одним-единственным глобальным классом, который хранит все-все функции. Ну и глобальные переменные тоже. О полморфизме и наследовании речь естественно не идёт. Зачем урезать себя в возможностях, если можно потратив некоторое время на обучение их получить?
Собственно мое отношение к ООП в 5-ой версии, вот минусы:
Одна из серьезных проблем ООП в PHP 5 - отсутствие модификатора наследования.
Отсутствие возможности множественного наследования.
Конструктор базового класса не вызывается по умолчанию из конструктора наследника.
Следствием отсутствия строгой типизации является отсутствие возможности перегрузки функций.
В PHP 5 есть возможность указать тип аргумента функции (только для классов и массивов). Если переданный аргумент не будет соответствовать требуемому типу, возникнет ошибка и функция вызвана не будет.
Отсутствие нормального определения виртуальных свойств и методов класса (свойств, которые имеют геттеры и сеттеры).
Открытость классов.
Смешение статических и нестатических методов и свойств.
А вообще:
Объектно-ориентированные языки поддерживают создание структур с большим количеством связующего кода и сложными уровнями. Это может оказаться полезным в случае, если предметная область является действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому, что им известны эти способы и они умеют ими пользоваться.
Эрик. С. Реймонд. Искусство программирования для UNIX.
Одна из серьезных проблем ООП в PHP 5 - отсутствие модификатора наследования.
Отсутствие возможности множественного наследования.
Конструктор базового класса не вызывается по умолчанию из конструктора наследника.
Следствием отсутствия строгой типизации является отсутствие возможности перегрузки функций.
В PHP 5 есть возможность указать тип аргумента функции (только для классов и массивов). Если переданный аргумент не будет соответствовать требуемому типу, возникнет ошибка и функция вызвана не будет.
Отсутствие нормального определения виртуальных свойств и методов класса (свойств, которые имеют геттеры и сеттеры).
Открытость классов.
Смешение статических и нестатических методов и свойств.
А вообще:
Объектно-ориентированные языки поддерживают создание структур с большим количеством связующего кода и сложными уровнями. Это может оказаться полезным в случае, если предметная область является действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому, что им известны эти способы и они умеют ими пользоваться.
Эрик. С. Реймонд. Искусство программирования для UNIX.
И PHP перерастёт в С++. Разве что добавить перегрузку операторов ещё :)
А вот отсуствие нормально определения виртуальных свойств можно по подробнее.
А вот отсуствие нормально определения виртуальных свойств можно по подробнее.
А в C# это всё есть ;)
Отсутствие возможности множественного наследования.
Это его достоинство а не недостаток.
http://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)#.D0.9C.D0.BD.D0.BE.D0.B6.D0.B5.D1.81.D1.82.D0.B2.D0.B5.D0.BD.D0.BD.D0.BE.D0.B5_.D0.BD.D0.B0.D1.81.D0.BB.D0.B5.D0.B4.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5
Это его достоинство а не недостаток.
http://ru.wikipedia.org/wiki/%D0%9D%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)#.D0.9C.D0.BD.D0.BE.D0.B6.D0.B5.D1.81.D1.82.D0.B2.D0.B5.D0.BD.D0.BD.D0.BE.D0.B5_.D0.BD.D0.B0.D1.81.D0.BB.D0.B5.D0.B4.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5
бред.
Про примеры даже говорить не хочется, там вообще бред полный.
Выбирать между ООП и процедурным подходом, все равно что выбирать из чего делать машину, только из железа или только из пластика.
Люди, используйте объекты там, где они действительно нужны. А где не нужны — процедуры. Процедуры тоже могут выглядеть приятно, красиво и эффективно, юзайте статические классы.
Про примеры даже говорить не хочется, там вообще бред полный.
Выбирать между ООП и процедурным подходом, все равно что выбирать из чего делать машину, только из железа или только из пластика.
Люди, используйте объекты там, где они действительно нужны. А где не нужны — процедуры. Процедуры тоже могут выглядеть приятно, красиво и эффективно, юзайте статические классы.
Странное сравнение "есть процедурный подход, а теперь следующие 99% поговорим о том, почему ООП это круто!". ИМХО из опыта, я бы тут согласился с Nod, "когда код перевалит за 20-30 строк тогда придется переходить на ООП" (я бы правда сказал и раньше).
Но большинство использует всегда ООП (даже для программ из сотен строк) - вот этого я не понимаю. Зачем? Если та же программа на функциях пишется в два раза быстрее и в два раза короче. Потому что не нужны описания всех мыслимых аксессоров, а только методов (функций). Плохо, что те, кто начинает с ООП считает его чем-то вроде Программирование 2.0, а процедурный подход чем-то вроде атавизма.
Для подтверждения два примера из моей жизни где было что: 0. ООП плохо 1. Функции плохо
0. ООП плохо
Была у меня задумка сделать конвертер из SketchUp в формат 3D Crysis'а, в общем, как известно очень сколняет к ООП (вообще, замечательный язык, только почему-то его почтоянно путают с Ruby on Rails, ну не суть). В общем, на ООП был написан конвертер, сделана модель из 30 тыс. полигонов (здоровое советское здание) и конвертер пошел. Он тужился около 40 минут, пока мне не надоело ждать. А суть в том, что Руби постоянно создавал в памяти новые объекты (chunk'и, содержащие отдельные полигоны) и на каждый из них требовалось время, чтобы его создать, чтобы сменить структуру родительского объекта (счетчики, массивы и т.п.), естественно, перераспределение памяти и т.п. и т.п. и т.п. Я переделал проект - заставил Руби только выплюнуть список вершин и фейсов. А затем PHP читал этот список и тупо, без памяти - писал прямо в файл то, что нужно (никаких overhead'ов на создание объектов, просто fseek-fputs-fseek-fputs).
Разница? ООП подход более 40 минут на полу-сложную модель, процедурный подход - менее 1 секунды на ту же модель (время исполнения, время написания кода тоже разное - объектный раза в три длиннее код был за счет описания всех аксессоров).
1. Процедуры плохо
В каком-то далеком году я понял, что мне нужна своя CMS, потому что все существующие являются перевариванием одних и тех же идей (админка отдельно от сайта со всякими списками сущностей и т.п., при чем зачастую даже терминология одна и та же). Проект я сделал - отдельного от сайта интерфейса вообще нет - начинаем с белого листа и выстраиваем на нем сайт и редактируем все прямо на месте, естественно, поскольку это было игрушкой в моем понимании - это писалось на функциях. Постепенно на эту систему стало использовать несколько студий, ее поставили на более чем 300 коммерческих сайтов, в общем, годы разработки и разраслось это все ужас.
Честно говоря, сейчас что-то в ней переделать становится все сложнее, получается так, что я уже давно жалею, что не стал ее на объектах писать.
ООП это благо, но к этому я бы еще добавил, что когда проект переваливает за 1 разработчика - то ООП тоже благо.
Но большинство использует всегда ООП (даже для программ из сотен строк) - вот этого я не понимаю. Зачем? Если та же программа на функциях пишется в два раза быстрее и в два раза короче. Потому что не нужны описания всех мыслимых аксессоров, а только методов (функций). Плохо, что те, кто начинает с ООП считает его чем-то вроде Программирование 2.0, а процедурный подход чем-то вроде атавизма.
Для подтверждения два примера из моей жизни где было что: 0. ООП плохо 1. Функции плохо
0. ООП плохо
Была у меня задумка сделать конвертер из SketchUp в формат 3D Crysis'а, в общем, как известно очень сколняет к ООП (вообще, замечательный язык, только почему-то его почтоянно путают с Ruby on Rails, ну не суть). В общем, на ООП был написан конвертер, сделана модель из 30 тыс. полигонов (здоровое советское здание) и конвертер пошел. Он тужился около 40 минут, пока мне не надоело ждать. А суть в том, что Руби постоянно создавал в памяти новые объекты (chunk'и, содержащие отдельные полигоны) и на каждый из них требовалось время, чтобы его создать, чтобы сменить структуру родительского объекта (счетчики, массивы и т.п.), естественно, перераспределение памяти и т.п. и т.п. и т.п. Я переделал проект - заставил Руби только выплюнуть список вершин и фейсов. А затем PHP читал этот список и тупо, без памяти - писал прямо в файл то, что нужно (никаких overhead'ов на создание объектов, просто fseek-fputs-fseek-fputs).
Разница? ООП подход более 40 минут на полу-сложную модель, процедурный подход - менее 1 секунды на ту же модель (время исполнения, время написания кода тоже разное - объектный раза в три длиннее код был за счет описания всех аксессоров).
1. Процедуры плохо
В каком-то далеком году я понял, что мне нужна своя CMS, потому что все существующие являются перевариванием одних и тех же идей (админка отдельно от сайта со всякими списками сущностей и т.п., при чем зачастую даже терминология одна и та же). Проект я сделал - отдельного от сайта интерфейса вообще нет - начинаем с белого листа и выстраиваем на нем сайт и редактируем все прямо на месте, естественно, поскольку это было игрушкой в моем понимании - это писалось на функциях. Постепенно на эту систему стало использовать несколько студий, ее поставили на более чем 300 коммерческих сайтов, в общем, годы разработки и разраслось это все ужас.
Честно говоря, сейчас что-то в ней переделать становится все сложнее, получается так, что я уже давно жалею, что не стал ее на объектах писать.
ООП это благо, но к этому я бы еще добавил, что когда проект переваливает за 1 разработчика - то ООП тоже благо.
Насчёт пункта 0. Никогда не приходилось слышать о шаблонах проектирования, в частности, о Flyweight? Это не проблема ООП, это проблема архитектуры.
О шаблонах проектирования - слышал, а о Flyweight - нет, пойду читать, спасибо за подсказку ) Поставил бы [+] в карму за совет, да кнопка не нажимабельна )
Я ж не утверждаю, что ООП это проблемы - просто иногда оно лучше, иногда проц-ый подход лучше. Раздражает то, что люди, в основном, видят только единственный вариант правильным (либо ООП, либо функции).
Я ж не утверждаю, что ООП это проблемы - просто иногда оно лучше, иногда проц-ый подход лучше. Раздражает то, что люди, в основном, видят только единственный вариант правильным (либо ООП, либо функции).
Ну прочитал я про Flyweight - смысл понял как "что-то типа нормализации в SQL" - выносите все общие данные, много раз повторяющиеся данные в один объект? Если так понял - то не подошел бы для того случая )
Дело в том, что там как раз очень много было мелких отличающихся объектов. Например, вершины (vertex), ну они все отличные - не расшарить их никак. Даже кэш был реализован, что если две вершины совпадают - использовать id старой, не плодить новый объект. И тем не менее оверхэд на создание и управление этим массивом классов вершин был такой, что память (4GB на 64 битах) помирала на десятках тысяч вершин. И я так понял, что постоянно происходило перевыделение памяти и перенос всего этого массива в новое место (если не вообще создание нового массива), поэтому и так тупило.
Дело в том, что там как раз очень много было мелких отличающихся объектов. Например, вершины (vertex), ну они все отличные - не расшарить их никак. Даже кэш был реализован, что если две вершины совпадают - использовать id старой, не плодить новый объект. И тем не менее оверхэд на создание и управление этим массивом классов вершин был такой, что память (4GB на 64 битах) помирала на десятках тысяч вершин. И я так понял, что постоянно происходило перевыделение памяти и перенос всего этого массива в новое место (если не вообще создание нового массива), поэтому и так тупило.
Зачем поляризировать подход к написанию кода в мультипарадигмальном языке?
Извините, но ваш перевод ужасен. :-( Почти все фразы звучат не по-русски. Читать практически невозможно. На вашем месте я бы подверг текст жёсткой редактуре.
НЛО прилетело и опубликовало эту надпись здесь
Ну честно говоря 2 куска кода разные совсем... я имею ввиду, вот если тоже самое "раскрыть" во втором куске кода полностью...
И честно говоря сравнивать ООП и процедурный вопрос в общих понятиях некоректно...
Здесь конечно ООП вне конкуренции, но если с умом... Недавно смотрел "проект" сделанный на "чистом" ООП - извините, но половину кода можно было смело заменить процедурным подходом и было бы гараздо понятливее и логичнее. Ну явный перегруз. Мало того из-за этого пострадал конечный пользователь системы. Так как весь этот ООП "плюхнулся" еще и в шаблоны и куда только можно. Я теперь посмотрю на глаза верстальщика который будет изменять шаблон...
А вообще я конечно за ООП... покажите мне пальцем кто против :) но с умом.
ООП - это ИНСТРУМЕНТ! Но далеко не АРХИТЕКТУРА!
И честно говоря сравнивать ООП и процедурный вопрос в общих понятиях некоректно...
Здесь конечно ООП вне конкуренции, но если с умом... Недавно смотрел "проект" сделанный на "чистом" ООП - извините, но половину кода можно было смело заменить процедурным подходом и было бы гараздо понятливее и логичнее. Ну явный перегруз. Мало того из-за этого пострадал конечный пользователь системы. Так как весь этот ООП "плюхнулся" еще и в шаблоны и куда только можно. Я теперь посмотрю на глаза верстальщика который будет изменять шаблон...
А вообще я конечно за ООП... покажите мне пальцем кто против :) но с умом.
ООП - это ИНСТРУМЕНТ! Но далеко не АРХИТЕКТУРА!
Если внимательно посмотреть на эти 2 куска кода то можно заметить, что код с использованием ООП более читабельный и легче для восприятия.
Если внимательно посмотреть на те два куска кода, то ООП будет вызывать только стойкое отвращение =\
Есть такая cms(cmf), зовут Drupal, которая на AWARD 2007 прекрасно показала, что отличный код и организация возможны на процедурном подходе, решения и код в ней такой по качеству, который не смогут реализовать половина "пишущих на ООП" в нашей стране. Так что можно плеваться на процедуры, а можно реально посмотреть на ситуацию и за что голосует планета (скорее всего в этом году это повторится).
Ни в коем случае не пропагандирую отказ от процедур, но и не надо утверждать, что "ООП структурированей и безбожно необходим", это так только на первый взгляд.
ps: кто понимает о чем я - поддержит, кто нет - скорее всего нажмет "минус".
Ни в коем случае не пропагандирую отказ от процедур, но и не надо утверждать, что "ООП структурированей и безбожно необходим", это так только на первый взгляд.
ps: кто понимает о чем я - поддержит, кто нет - скорее всего нажмет "минус".
Drupal написан без объектов? Я так понял?
С объектами, но минимум классов и нет наследований. В общем прежде чем плеваться нужно разобраться, разговор в одну сторону не принесет никому пользы.
Дык а я разве спорил в одну сторону - посмотрите мой коммент yoihj 16 апреля 2008 18:11 - там аргементы и в одну, и в другую сторону - я как раз за разнообразие, просто было интересно узнать этот вопрос.
ок, я понял, просто, чтоб не думали плохо о друпал :) все там более чем серьезно и правильно.
Сам я впервые наткнулся на него, когда гуглил на на тему переопределяемых функций в php (такое есть в С++, но нет php) и попал на друпал, вот.
Что касается человека ниже - с джумлой даже ровнять нечего - это разные плоскости разработки.
Сам я впервые наткнулся на него, когда гуглил на на тему переопределяемых функций в php (такое есть в С++, но нет php) и попал на друпал, вот.
Что касается человека ниже - с джумлой даже ровнять нечего - это разные плоскости разработки.
Это всего лишь доказывает, что в жюри были некомпетентные люди... До того, как увидел в его стандартных модулях смешанную с представление логику, я думал о друпале лучше. А это, оказывается, ещё одна джумла.
Абсолютно согласен - Drupal это просто кошмарный ужас для верстальщика - шаг влево, шаг вправо от зашитого в код HTML - карается жутчайшим геморроем.
вы заблуждаетесь, в нем нет зашитого кода, видимо не разобрались.
И со стороны программиста (ни одной строки) ни со стороны верстальщика.
И со стороны программиста (ни одной строки) ни со стороны верстальщика.
Примеров множество. Я не работаю с Drupal, однако вижу, например, такое: drupal/modules/book/book.module:
if ($tree = book_tree_recurse($parent, $depth, $children, $unfold)) {
return '<ul class="menu">'. $tree .'</ul>';
}
Я вижу, что вы не работаете с друпал, этот модуль - ненужная функциональность, которая нигде не используется.
Смотрите на такие вещи как таксономия, ноды, cck, и не забывайте, что часть кода может быть представлена для интерфейса настройки в админ части (ориентируйтесь на то что написано в *_menu), автор может туда вложить инлайн-код, но мешать он вам никогда не будет, и то врядли найдете.
И еще - не надо разводить полемику, это некрасиво и абсолютно песполезно задавить такую систему глянув в бестолковый модуль и не попробовав ее саму в работе. Если есть реальные вопросы - эта тема не подходит, но могу ответить в ЛС.
Смотрите на такие вещи как таксономия, ноды, cck, и не забывайте, что часть кода может быть представлена для интерфейса настройки в админ части (ориентируйтесь на то что написано в *_menu), автор может туда вложить инлайн-код, но мешать он вам никогда не будет, и то врядли найдете.
И еще - не надо разводить полемику, это некрасиво и абсолютно песполезно задавить такую систему глянув в бестолковый модуль и не попробовав ее саму в работе. Если есть реальные вопросы - эта тема не подходит, но могу ответить в ЛС.
жюри - голоса со всей планеты.
НЛО прилетело и опубликовало эту надпись здесь
О боже! Спасибо, что просветили. А то я на друпале что-то делать даже хотел. Теперь даже и близко не подойду :))
ну опять понеслась... войны инструментов
всеравно будут юзать и процедуры и функции и классы, вмести и раздельно; тыщу раз уже писали про это и говорили, что от проекта зависит и тд. К чему опять все заново? Перетащить все еще сомневающихся на ООП? Зачем? Лично знаком с организацией где было запрещено!!!, да-да, использовать классы вообще, мотивируя это плохой сопровождаемостью кода другими програмерами (очевидно теми, которые не в теме). Ибо криво написаный, не отформатированый, не задокументированый класс, это головная боль.
всеравно будут юзать и процедуры и функции и классы, вмести и раздельно; тыщу раз уже писали про это и говорили, что от проекта зависит и тд. К чему опять все заново? Перетащить все еще сомневающихся на ООП? Зачем? Лично знаком с организацией где было запрещено!!!, да-да, использовать классы вообще, мотивируя это плохой сопровождаемостью кода другими програмерами (очевидно теми, которые не в теме). Ибо криво написаный, не отформатированый, не задокументированый класс, это головная боль.
просто у кого-то шило в одном месте и ему неймётся доказать всему свету, что ООП рулит. Этот топик смотрелся бы лаконичнее в разделе "юмор".
Ну как надоели мне эти "Крутые ООПэшники", которые тупо не могут для большей совместимости в классе DB, после соединения с базой, явно указать кодировку, в которой ей отдавать данные. Заметил, что в сайтах написанных процедурным подходом такие косяки намного реже. Зато ООП, блин.
Ну как надоели мне эти "Крутые ООПэшники", которые тупо не могут для большей совместимости в классе DB, после соединения с базой, явно указать кодировку, в которой ей отдавать данные. Заметил, что в сайтах написанных процедурным подходом такие косяки намного реже. Зато ООП, блин.
Во многих случаях использование ООП-методов похожу на использование молотка для того, что бы убить муху.
Уровень абстракций, предлагаемых ООП-методами, часто является излишним для решения простых задач.Тем не менее, чем сложнее система, тем эффективнее будут решения на основе ООП.
Уровень абстракций, предлагаемых ООП-методами, часто является излишним для решения простых задач.Тем не менее, чем сложнее система, тем эффективнее будут решения на основе ООП.
Имею наглость учить ПХП детей. Поэтому скажу чисто теоретически.
Объекты важны по многим пречинам: это и упрощение кода и понятная человеку логика построения.
То что объектный подход медлене - можно переписать критичные куски кода процедурно.
НО это отнюдь не единственный подход сделать себе жизнь проще. Взять Смати - система шаблонов генерирует исполняемый код. И поэтому код очень эффективен.
Есть еще автоматный подход, но там своя логика, отличная от процедурной.
Нет царского пути ни в ПХП ни где бы то нибыло еще!
А статья - что статья? Хорошая, но слишком тривиальная. Я люблю по горячее.
Объекты важны по многим пречинам: это и упрощение кода и понятная человеку логика построения.
То что объектный подход медлене - можно переписать критичные куски кода процедурно.
НО это отнюдь не единственный подход сделать себе жизнь проще. Взять Смати - система шаблонов генерирует исполняемый код. И поэтому код очень эффективен.
Есть еще автоматный подход, но там своя логика, отличная от процедурной.
Нет царского пути ни в ПХП ни где бы то нибыло еще!
А статья - что статья? Хорошая, но слишком тривиальная. Я люблю по горячее.
простите, но я в шоке...
«пречинам: это и упрощение кода и понятная человеку логика построения.»
прИчинам - это и упрощение кода, и понятная человеку логика построения.
«То что объектный подход медлене - можно переписать критичные куски кода процедурно.
» где логика предложения, вообще?
действительно, имеете большую наглость учить детей
«пречинам: это и упрощение кода и понятная человеку логика построения.»
прИчинам - это и упрощение кода, и понятная человеку логика построения.
«То что объектный подход медлене - можно переписать критичные куски кода процедурно.
» где логика предложения, вообще?
действительно, имеете большую наглость учить детей
Однозначно ООП. у меня руки не поднимаются писать функции (методы) в глобальной видимости (т.е. писать вспомогательные функции в открытом доступе. а не в классе с private доступом
я думаю, что однозначно ООП лучше процедурного кода. Если люди говорят, что вот процедуры лучше использовать для маленьких проектов, то я в корне не согласен, так как можно создать даже статический класс с набором методов, но это даст возможность все систематизировать и понять через пол года что где и как. Но зачастую люди спешат и не хотя задумываться какие классы можно создать, то есть не проводят объектный анализ. И мне кажется не из-за того, что так хуже, а из-за того что это быстрее, соответственно можно быстрее получить деньги:)
Ну а с большими проектами все по другому, там без толковой проектировки никуда.
P.S. Еще много эмоций в голове. И вообще думаю подобные темы не приводят к конструктиву, а разводят бесполезные споры.
Ну а с большими проектами все по другому, там без толковой проектировки никуда.
P.S. Еще много эмоций в голове. И вообще думаю подобные темы не приводят к конструктиву, а разводят бесполезные споры.
надо писать так, чтобы через год хотя бы самому понять что написано. А с на ООП это будет или одними процедурами - фиолетово.
Моя мама - программист. Она писала в машинных кодах для ЕС ЭВМ и прочих экзотичесих машин. Дома хранится перфолента "Вова + Надя = Любовь". Вова это мой папа.
Кроме перфоленты, оберегается книга Денни Ван Тассела "Стиль, разработка, эффективность, отладка и испытание программ". Эта книга - примерно моя ровесница. И в ней, понятное дело, объектно-ориентированным программированием и не пахнет.
Одна из главных мыслей книги - такая: программы нужно делать понятными, легко модифицируемыми и модульными. При чём, модули лучше делать независимыми, а значит - заменяемыми.
Очень похоже на цели принципов ООП, хотя, примеры в книге приводятся одновременно на процедурном, функциональном и, если не ошибаюсь, линейном языках каждый. То есть, на трёх языках с разной парадигмой.
Безусловно, ООП облегчает процесс разработки модульных программ. Однако, само по себе использование ООП не гарантирует что модули вашей программы можно будет повторно использовать, либо безболезненно заменять.
ООП - не панацея от плохих программ и, тем более, плохих программистов. Плохо писать можно и на смолтоке и на лиспе, и на C++.
Панацея от плохих программ - грамотное проектирование и здравый смысл.
Конечно, ООП облегчает реализацию модулей и дисциплинирует. Чего стоят одни только шаблоны проектирования. Невозможно реализовать какую-нибудь там абстрактную фабрику в виде процедуры (вернее, возможно, но это не будет так же легко читаться). Но это не значит, что без использования ООП нельзя сделать легко поддерживаемую, эффективную и модифицируемую программу.
Основополагающие принципы разработки программ были сформулированы гораздо раньше принципов ООП, и, по большому счёту, независимы от парадигмы программирования.
Спорить о преимуществах того или иного подхода бессмысленно. Я вот, например, люблю велосипед больше чем роликовые коньки и считаю, что он ездит быстрее, но как-то раз не смог угнаться на нём за бывшей фигуристкой-роллершей.
Кроме перфоленты, оберегается книга Денни Ван Тассела "Стиль, разработка, эффективность, отладка и испытание программ". Эта книга - примерно моя ровесница. И в ней, понятное дело, объектно-ориентированным программированием и не пахнет.
Одна из главных мыслей книги - такая: программы нужно делать понятными, легко модифицируемыми и модульными. При чём, модули лучше делать независимыми, а значит - заменяемыми.
Очень похоже на цели принципов ООП, хотя, примеры в книге приводятся одновременно на процедурном, функциональном и, если не ошибаюсь, линейном языках каждый. То есть, на трёх языках с разной парадигмой.
Безусловно, ООП облегчает процесс разработки модульных программ. Однако, само по себе использование ООП не гарантирует что модули вашей программы можно будет повторно использовать, либо безболезненно заменять.
ООП - не панацея от плохих программ и, тем более, плохих программистов. Плохо писать можно и на смолтоке и на лиспе, и на C++.
Панацея от плохих программ - грамотное проектирование и здравый смысл.
Конечно, ООП облегчает реализацию модулей и дисциплинирует. Чего стоят одни только шаблоны проектирования. Невозможно реализовать какую-нибудь там абстрактную фабрику в виде процедуры (вернее, возможно, но это не будет так же легко читаться). Но это не значит, что без использования ООП нельзя сделать легко поддерживаемую, эффективную и модифицируемую программу.
Основополагающие принципы разработки программ были сформулированы гораздо раньше принципов ООП, и, по большому счёту, независимы от парадигмы программирования.
Спорить о преимуществах того или иного подхода бессмысленно. Я вот, например, люблю велосипед больше чем роликовые коньки и считаю, что он ездит быстрее, но как-то раз не смог угнаться на нём за бывшей фигуристкой-роллершей.
НЛО прилетело и опубликовало эту надпись здесь
Ндэ?
Парадигма ООП предполагает другой подход к проектированию. Декомпозиция задачи делается с точки зрения её ключевых сущностей и методов их взаимодействия между собой. Что даёт другой уровень абстракции и помогает справиться со сложностью задачи. Сами же методы могут представлять из себя, скажем, вызовы SQL. И вот уже стиль стал где-то декларативным. Можно и функциональный стиль построить.
Лучше бы Вам вначале разобраться с терминами. Мож тогда и подташнивать меньше будет. :-)
Парадигма ООП предполагает другой подход к проектированию. Декомпозиция задачи делается с точки зрения её ключевых сущностей и методов их взаимодействия между собой. Что даёт другой уровень абстракции и помогает справиться со сложностью задачи. Сами же методы могут представлять из себя, скажем, вызовы SQL. И вот уже стиль стал где-то декларативным. Можно и функциональный стиль построить.
Лучше бы Вам вначале разобраться с терминами. Мож тогда и подташнивать меньше будет. :-)
Можно купить и прочесть книгу П.Ловэйна на эту тему, тем более, что стоит она совсем недорого и издана по-русски, и не мучиться с переводами :-)
Несомненно плюс - топик хороший.
В конце было бы также неплохо привести ссылки на хорошие книги, посвященные ООП в PHP.
В конце было бы также неплохо привести ссылки на хорошие книги, посвященные ООП в PHP.
НЛО прилетело и опубликовало эту надпись здесь
Из практики.
Есть люди, которые просто не могут писать код на ООП, ну не могут некоторые говорить в терминах "объект", "сделал", "умеет", "обладает". И в то же время это высококлалифицированные проффесионалы, которые хорошо решают поставленные задачи. Заставлять таких людей работать в принципах ООП не оправданно. Нужно понимать, что иногда заставляя программиста писать на ооп вы можете заставить писать его хуже или разойтись с ним.
ООП - это уровень абстракций комуто близкий кому-то нет.
Есть люди, которые просто не могут писать код на ООП, ну не могут некоторые говорить в терминах "объект", "сделал", "умеет", "обладает". И в то же время это высококлалифицированные проффесионалы, которые хорошо решают поставленные задачи. Заставлять таких людей работать в принципах ООП не оправданно. Нужно понимать, что иногда заставляя программиста писать на ооп вы можете заставить писать его хуже или разойтись с ним.
ООП - это уровень абстракций комуто близкий кому-то нет.
А вот тот же кусок кода с использованием нормального ООП:
Валидация данных - до вашего кода, если Вы задекларировали это!
Соединение с базой данных - до вашего кода, если Вы задекларировали это!
Попытка вставки данных - реального рендеринга!
$model->insert($me);
$reports-render($me);
Сорри, за категоричность, но честно, удивили Ваши зарисовки.
Валидация данных - до вашего кода, если Вы задекларировали это!
Соединение с базой данных - до вашего кода, если Вы задекларировали это!
Попытка вставки данных - реального рендеринга!
$model->insert($me);
$reports-render($me);
Сорри, за категоричность, но честно, удивили Ваши зарисовки.
я думаю, что ООП надо использовать, но надо использовать К МЕСТУ
правильно где-то прочитал, что некоторые фанатики ООП пишут класс для сложения двух чисел, а зачем?
мне кажется, что основную структуру можно сделать на ООП, но при условии, что число строк кода первышает 1000
для маленьких приложений (простейшая гостевая книга, например, или примитивные новости) ООП не нужен, потому как с этим кодом разберется любой новичок в программировании вообще
правильно где-то прочитал, что некоторые фанатики ООП пишут класс для сложения двух чисел, а зачем?
мне кажется, что основную структуру можно сделать на ООП, но при условии, что число строк кода первышает 1000
для маленьких приложений (простейшая гостевая книга, например, или примитивные новости) ООП не нужен, потому как с этим кодом разберется любой новичок в программировании вообще
Вообще на PHP нападают все кому не лень. И С/С++, С шарписты (C#), и Java и питонисты, и дельфисты и.т.д., причём замечу что в основном это одностороннее - все орут на PHP, а PHP разработчики отбиваются и никого как правило не хаят.
Многие видят проблемы PHP там, где их реально нет - проблема в слепости и однобокости подхода или не желании подумать, или даже в нехватки знаний и воображения. Так же часто упёртость по типу "Я пишу на функциях, значит здесь объекту делать нечего" или наоборот. В 99% случаев это в корне не верно. Надо уметь мешать функции и ООП, надо делать так, что бы работало быстро и было удобно для програмиста. Не нужно прикручивать что-то монструозное для среднего проекта, так же как и не стоит брать что-то среднее по размеру для монструозного проекта. Тоесть надо уметь соотносить размер проекта и размер используемой системы, архитектуры и подхода. Для небольших проектов (небольшой сайт компании с некоторым специфичным функционалом) - функции или возможно постейший базовый класс который делает минимум функционала - грузит модули и возможно обеспечивает права доступа - с использованием функций.
Средний проект - уже с упором на объектную модель, с более-менее сложной логикой но и про функции забывать не стоит. Перегружать всякими мега-ооп штуками тоже не стоит - повышение сложности понимания да и на время разработки особо не повлияет.
Большой проект - вот тут уже в основном чистый ООП подход. Модули таких систем как правило не маленькие и OOP overhead в данном случае будет просто стремится к нулю. Конечно нужно делать с умом, не стоит делать небольшой объект только ради контейнера для десятка функций, специфичных для пары модулей - вынесите в фаил и делайте include.
Моё мнение таково, что большинство не умеют или не хотят видеть ту границу разумности. Они просто делают, потом оказывается что всё плохо, да уже поздно. Кто-то перепишет, а кто-то будет костылять дальше из-за невозможности всё переделать.
Многие видят проблемы PHP там, где их реально нет - проблема в слепости и однобокости подхода или не желании подумать, или даже в нехватки знаний и воображения. Так же часто упёртость по типу "Я пишу на функциях, значит здесь объекту делать нечего" или наоборот. В 99% случаев это в корне не верно. Надо уметь мешать функции и ООП, надо делать так, что бы работало быстро и было удобно для програмиста. Не нужно прикручивать что-то монструозное для среднего проекта, так же как и не стоит брать что-то среднее по размеру для монструозного проекта. Тоесть надо уметь соотносить размер проекта и размер используемой системы, архитектуры и подхода. Для небольших проектов (небольшой сайт компании с некоторым специфичным функционалом) - функции или возможно постейший базовый класс который делает минимум функционала - грузит модули и возможно обеспечивает права доступа - с использованием функций.
Средний проект - уже с упором на объектную модель, с более-менее сложной логикой но и про функции забывать не стоит. Перегружать всякими мега-ооп штуками тоже не стоит - повышение сложности понимания да и на время разработки особо не повлияет.
Большой проект - вот тут уже в основном чистый ООП подход. Модули таких систем как правило не маленькие и OOP overhead в данном случае будет просто стремится к нулю. Конечно нужно делать с умом, не стоит делать небольшой объект только ради контейнера для десятка функций, специфичных для пары модулей - вынесите в фаил и делайте include.
Моё мнение таково, что большинство не умеют или не хотят видеть ту границу разумности. Они просто делают, потом оказывается что всё плохо, да уже поздно. Кто-то перепишет, а кто-то будет костылять дальше из-за невозможности всё переделать.
Кстати, первый-то кусок кода лично мне, непрограммисту, более понятен, чем второй.
Да, первый кусок полон, понятен и работает как есть (скопировал и почти все будет работать), а во втором еще сокрыта реализация классов (несколько десятков строк кода и коментов, без которых будет вообще непонятно как все это использовать).
Кто больше программировал процедурно - легче читает первый кусок. ООП-эшник легче прочитает второй. Это дело больше привычки программиста, а не читаемости кода.
И даже больше скажу: часть людей склонны к процедурному мышлению, часть к ООПэшному.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP — ООП или процедурный подход