Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 124
OsCommerce насквозь пропитан костылями а не ООП
400-600Кб ручного кода для ресурса поднятого с нуля — очень немного, посути движок, средства работы с бд, средства работы с шаблонами и обвяз для основных модулей/компонентов, любой маломальский магазин написанный в ручную с нуля это уже больше 400Кб.
400-600Кб ручного кода для ресурса поднятого с нуля — очень немного, посути движок, средства работы с бд, средства работы с шаблонами и обвяз для основных модулей/компонентов, любой маломальский магазин написанный в ручную с нуля это уже больше 400Кб.
можно открывать хаб-еженедельник — «Новости ООП»
Чёт у вас плохие примеры. Хороший пример — марсоход. 2.5 ляма строк кода на чистом С без ООП. Но там для этого были причины.
В целом могу сказать, что вы неправильно усвоили паратидигмы ООП. Видимо всему виной PHP, в котором ООП кастрирован. Попробуйте, например, Java. Она форсит использование ООП. Через годик проникнитесь концепцией и сможете более взвешенно рассуждать о плюсах и минусах.
p.s. а как получилось цифра 12%? Точно не 12.5?
В целом могу сказать, что вы неправильно усвоили паратидигмы ООП. Видимо всему виной PHP, в котором ООП кастрирован. Попробуйте, например, Java. Она форсит использование ООП. Через годик проникнитесь концепцией и сможете более взвешенно рассуждать о плюсах и минусах.
p.s. а как получилось цифра 12%? Точно не 12.5?
ой беда…
*парадигмы
*получилась
*парадигмы
*получилась
Подскажите в чем именно «кастрированность» ООП в PHP 5.4
А с чего вы взяли, что эти 2,5 миллиона строк кода без ООП? Или, если С, то сразу — не ООП?
Сомневаюсь, что в марсоходе не используются принципы инкапсуляции и абстрагирования.
Мы пишем кодеки на С с таким ООП, что любой С++ обзавидуется.
Мы пишем кодеки на С с таким ООП, что любой С++ обзавидуется.
Попробуйте, например, Java. Она форсит использование ООП.Если бы стояла задача выучить ООП, то вы были бы правы на 200%. А так — чел на PHP бабки зарабатывает. И понял, что ООП для него в этом деле — как пятое колесо в телеге. И тут он прав. Единственнное, в чём с ним не стоит соглашаться — это в обобщении этого ввода на области, лежащие за пределами области его деятельности.
ООП это средство управления сложностью программы. Если программа несложная — чего удивляться, что она хорошо живет без ООП?
Для ООП разработаны шаблоны проектирования. Их, мне кажется, трудно будет применить не имея классов.
Хорошо написанную ООП-программу сложнее испортить, когда в неё лезет новый человек.
И чем дальше, тем меньше можно найти людей, которые сумеют грамотно спроектировать программу без ООП — у них получится мешанина с кучей перекрёстных связей.
ООП стандарт де факто и в этом его сила, имхо.
Хорошо написанную ООП-программу сложнее испортить, когда в неё лезет новый человек.
И чем дальше, тем меньше можно найти людей, которые сумеют грамотно спроектировать программу без ООП — у них получится мешанина с кучей перекрёстных связей.
ООП стандарт де факто и в этом его сила, имхо.
Сорри за оффтоп, но на всех сайтах дырка с sql injection, а на xpectik.com.ua/ еще и вывод ошибок включен.
А еще xpectik.com.ua позволяет оформить пустую корзину, не указав ни одного обязательного поля (они там звездочками отмечены, как и везде).
А если будите продвигаться, SEO вас возненавидит за такие урлы: xpectik.com.ua/product_info.php?id=200&cat=1000
А если будите продвигаться, SEO вас возненавидит за такие урлы: xpectik.com.ua/product_info.php?id=200&cat=1000
Здравствуйте киевлянин:
Адрес IP 213.169.78.251
IP сеть Home Network 1
Имя хоста itc-251.naverex.kiev.ua
Неплохая попытка особенно: «xpectik.com.ua/product_id=150 ORDER BY 1&cat=14» при том что стоит intval ) да дырку получилось найти)))
Адрес IP 213.169.78.251
IP сеть Home Network 1
Имя хоста itc-251.naverex.kiev.ua
Неплохая попытка особенно: «xpectik.com.ua/product_id=150 ORDER BY 1&cat=14» при том что стоит intval ) да дырку получилось найти)))
Статья Я не знаю ООП хотя бы была интересной. А тут просто потрачена пара минут времени на чтение зря. И ещё минут 5 бесполезных эмоций из серии «нет слов».
Проблема в том, что многие понимают ООП слишком буквально. Мол, если ООП — то обязательно «в лоб» дробить задачу на классы, классы на подклассы, десятки уровней наследования, если язык позволяет — ромбовидное наследование и т.п.
Проблема не в ООП, а в том, как люди его понимают.
В своей статье я уже рассмотрел вполне ООП реализацию, которая, тем не менее, позволяет избавится от недостатков, привносимых «лобовыми» реализациями.
Проблема не в ООП, а в том, как люди его понимают.
В своей статье я уже рассмотрел вполне ООП реализацию, которая, тем не менее, позволяет избавится от недостатков, привносимых «лобовыми» реализациями.
Думаете смысл инкапсуляции в выносе данных в отдельные файлы? На самом деле, это подход к программированию, не с точки зрения функций, а сточки зрения данных. «Отталкиваясь» от данных.
А вообще, стандартная статья человека, не разобравшегося в ООП
А вообще, стандартная статья человека, не разобравшегося в ООП
Как по горстке типовых сайтов (аля куча страничек + каталог) можно говорить за или против ООП? У Вас просто не было необходимости в его использовании, проекты слишком маленькие, имхо.
Хочу, чтобы сделали хаб вроде «За и против ООП», я от него отпишусь.
Бедняга, навлек на себя столько гнева. По сути преимущество ООП сводится в абстрактным сущностям, с чем проще работать человеческому мозгу.
Я согласен, можно создавать абстрактные сущности, и работать на чистом функциональном подходе. Но функциональный подход требует от человека организованности, четкого представления сущностей, педантичности.
ООП предлагает нам паттерн организации кода. Но любой паттерн можно интерпретировать по-своему, почему и пишутся плохие реализации приложений на ООП, людьми, не понимающими что такое сущность, декомпозиция. И кстати, при декомпозиции тоже стоит знать меру.
Я согласен, можно создавать абстрактные сущности, и работать на чистом функциональном подходе. Но функциональный подход требует от человека организованности, четкого представления сущностей, педантичности.
ООП предлагает нам паттерн организации кода. Но любой паттерн можно интерпретировать по-своему, почему и пишутся плохие реализации приложений на ООП, людьми, не понимающими что такое сущность, декомпозиция. И кстати, при декомпозиции тоже стоит знать меру.
— «fastchange.com.ua» так все таки, «огромная масса», или 4.5 часа?
А вообще, пока у вас проекты на пару дней работы, и они не развиваются годами, все ок, можно и без ООП, можно даже лапшой (если не стыдно), да еще с html перемешать, все равно работать будет, пока кто-нибудь туда не влезет, чтобы что-то поправить, и не перепишет все заново, потому что это проще, чем внести серьезные изменения в существующий код.
эх, помню достался мне давным давно один проект (форум) на развитие, index.php и полторы-две (точно не помню) тысячи строк лапши из if-else в нем, даже функций почти не было. А я был молодым, малоопытным программистом, и не мог заявить «давайте выбросим это шлак, и сделаем по человечески, дешевле выйдет». Вот это был ад, его развивать, и меньше 400 кб код весил думаю :)
А по поводу прироста скорости на 3000%, ну ничего удивительного, вы сравнили универсальное решение (OsCommerce) и узко заточенный под проект код, на таких мелкий проектах, ничего удивительного в таком приросте. Но вот если бы вы разобрались в ООП и написали ООП решение под эти проекты, вы бы заметили, что расходы на ООП совсем мизерные. А поддерживать и развивать значительно удобнее.
И ООП это далеко не только инкапсуляция-наследование-полиморфизм. Почитайте паттерны проектирования (не обязательно PHP), они позволят вам взглянут на это по новому. Можно их даже не заучивать, они ценны как способ понять, что на самом деле может ООП.
«считаться ООП-ешником» :)
А вообще, пока у вас проекты на пару дней работы, и они не развиваются годами, все ок, можно и без ООП, можно даже лапшой (если не стыдно), да еще с html перемешать, все равно работать будет, пока кто-нибудь туда не влезет, чтобы что-то поправить, и не перепишет все заново, потому что это проще, чем внести серьезные изменения в существующий код.
эх, помню достался мне давным давно один проект (форум) на развитие, index.php и полторы-две (точно не помню) тысячи строк лапши из if-else в нем, даже функций почти не было. А я был молодым, малоопытным программистом, и не мог заявить «давайте выбросим это шлак, и сделаем по человечески, дешевле выйдет». Вот это был ад, его развивать, и меньше 400 кб код весил думаю :)
А по поводу прироста скорости на 3000%, ну ничего удивительного, вы сравнили универсальное решение (OsCommerce) и узко заточенный под проект код, на таких мелкий проектах, ничего удивительного в таком приросте. Но вот если бы вы разобрались в ООП и написали ООП решение под эти проекты, вы бы заметили, что расходы на ООП совсем мизерные. А поддерживать и развивать значительно удобнее.
И ООП это далеко не только инкапсуляция-наследование-полиморфизм. Почитайте паттерны проектирования (не обязательно PHP), они позволят вам взглянут на это по новому. Можно их даже не заучивать, они ценны как способ понять, что на самом деле может ООП.
«считаться ООП-ешником» :)
«истинным ООП-ком», звучит сильно… ;-)
Я только замечание по поводу русского языка: «В этот же момент я пропишу немного материала, которая позволит исключить часть негатива, который вызывает данный пост в истинных ООП-ков.» Как-то прям режет по мозгу предложение.
4 человекочаса — объёмный проект, показательный.
«Я уже более 6-ти лет программирую на PHP» — пожалуйста, поставьте реальный стаж, или уберите о нем вообще упоминание, не позорьте профессию. Малый опыт это не стыдно, все когда-то начинали, а вот делать такие сайты (я про качество) с шестилетним опытом, это уже стыдно, вот после такого и думают люди о php-шниках плохо :(
за 6 лет «программирования», можно было бы уже и разобраться с ООП
Оно в PHP недавно появилось.
«Пятая версия PHP была выпущена разработчиками 13 июля 2004 года. » ©Википедия
Уже восемь лет прошло, за такое время не только ООП в PHP можно было выучить.
Уже восемь лет прошло, за такое время не только ООП в PHP можно было выучить.
совсем недавно, лет 8 назад.
А когда PHP 5 стали поддерживать хостеры? А когда PHP 5 стал мейнстримом?
А причём тут это? Или отсутствие PHP 5 у хостеров мешает установить его локально в учебных целях?
Ну вообще примерно с этого времени хостеры (нормальные хостеры) и начали поддерживать PHP5…
И вообще не понял каким боком Вы приплели к вопросу хостеров? Что мешает взять дедик или VDS и поставить и использовать всё что душе угодно?
И вообще не понял каким боком Вы приплели к вопросу хостеров? Что мешает взять дедик или VDS и поставить и использовать всё что душе угодно?
Если вы это говорите мне, то лучше спросить сразу, зачем писать на PHP когда есть Java. Если автору, то он клепает сайты на заказ, и хостера ему скорее всего навязывает заказчик.
Объясните мне какая связь между PHP и тем какой хостинг требует заказчик?!
Сейчас валом хостеров, которые предлагают даже самые простые shared решения как с php 5, так и с вашей Java. Если чего то не хватает, покупайте VDS, сейчас есть предложения где VDS стоит от 10-25$
Сейчас валом хостеров, которые предлагают даже самые простые shared решения как с php 5, так и с вашей Java. Если чего то не хватает, покупайте VDS, сейчас есть предложения где VDS стоит от 10-25$
Заказчик не «требует» хостинг, а уже купил его, и сообщает адрес, логин и пароль к нему. Когда-то давно хостин мог не поддерживать PHP 5, а только PHP 4.
С VDS всплывает проблема — кто будет заниматься администрированием ОС и остальной среды выполнения приложения, хотя бы банально запускать apt-get update && apt-get upgrade и разбираться в случае проблем.
Да, разбирался я в ООП, и программировал около 1 года с использованием ООП, может и не разобрался до конца, хотя срок не маленький, может и попробую вернутся и настроиться под работу на ООП, но явно не скоро.
а программирую реально 6-ть лет, но у нас разные понятия про «качество», в связи что если человеку нужно дешево, я не буду проверять все и вся, только основу.
а программирую реально 6-ть лет, но у нас разные понятия про «качество», в связи что если человеку нужно дешево, я не буду проверять все и вся, только основу.
Качество есть качество, за дополнительную плату можно конечно улучшить качество до уровня выше среднего (особая надежность,, безопасность, покрытие кода юинт тестами и пр.), но средний уровень слабо коррелирует с ценой, только с опытом. Но 6 лет должно быть достаточно, чтобы научится делать фильтрацию (я про матрасы). Ну должна быть какая-то профессиональная гордость. Если клиент не в состоянии оплатить время которое нужно на разработку нормального продукта, может стоит отказаться от него? Если все так будут делать, может не будет больше клиентов, которые хотят сайт за 100$ Причем, в основном, это разочарованные клиенты (после получения продукта), и через некоторое время они опять платят деньги чтобы сделать нормально заново. Ну и имхо, сайты на 2-3 человеко-дня удел новичков (да простят меня новички), вы 6 лет делаете сайты, примеры которых вы указали в посте? Не скучно?
Зато теперь я полностью знаю куда я посылаю клиента, которому нужно очень дешево :)
«Да, разбирался я в ООП, и программировал около 1 года с использованием ООП, может и не разобрался до конца» — если вы об ООП знаете только то что указали в посте, то вы вообще не разобрались, простите за откровенность. Мне в свое время открыла глаза эта книга . PHP там нет совсем, но они универсальны, попробуйте.
Зато теперь я полностью знаю куда я посылаю клиента, которому нужно очень дешево :)
«Да, разбирался я в ООП, и программировал около 1 года с использованием ООП, может и не разобрался до конца» — если вы об ООП знаете только то что указали в посте, то вы вообще не разобрались, простите за откровенность. Мне в свое время открыла глаза эта книга . PHP там нет совсем, но они универсальны, попробуйте.
Уже много раз переходил к большим и более оплачиваемым проектам, но как показал свой опыт, чем больше проект, тем больше проблем, и стоимость часа работы падает.
Интернет-магазин, заточен по потребностям + верстка хтмл +наполнение за 250-300у.е., + делается за 1-3 дня, я думаю это дешево. Конечно же если клиент хочет более качественно и планирует более крупный по нагрузкам магазин, то там можно и больше посидеть. Но, и то стараюсь за такое не браться, клиентов масса и можно «перебирать» и делать по 10-15 сайтов в мес, мне достаточно :)
Очень благодарен за комментарии, самые нужные и по-делу. Книжку прочитаю, когда будет возможность
Интернет-магазин, заточен по потребностям + верстка хтмл +наполнение за 250-300у.е., + делается за 1-3 дня, я думаю это дешево. Конечно же если клиент хочет более качественно и планирует более крупный по нагрузкам магазин, то там можно и больше посидеть. Но, и то стараюсь за такое не браться, клиентов масса и можно «перебирать» и делать по 10-15 сайтов в мес, мне достаточно :)
Очень благодарен за комментарии, самые нужные и по-делу. Книжку прочитаю, когда будет возможность
Спасибо, интересная финансовая информация. В той сфере, за которую вы не «стараетесь не браться», ООП и вправду не нужно.
За написание кода, который должен работать под Joomla и Drupal, вы тоже стараетесь не браться?
За написание кода, который должен работать под Joomla и Drupal, вы тоже стараетесь не браться?
Есть мнение, что в случе хорошего овладения ООП количество часов работы на проект снизится, и можно будет браться за более сложные проекты.
Если все так будут делать, может не будет больше клиентов, которые хотят сайт за 100$ Причем, в основном, это разочарованные клиенты (после получения продукта), и через некоторое время они опять платят деньги чтобы сделать нормально заново
- За 100$ чел попробовал, что такое сайт, и чётче прояснил для себя что он хочет.
- Когда чел будет платить деньги чтобы сделать нормально заново, он заплатит явно больше 100$, так что эта сотня по сравнению с той суммой — мелочь.
Мне в свое время открыла глаза эта книгаС дизайн-паттернами столкнулся в первый раз на собеседовании. «Поплыл», ибо не перед этим вечером не дали подготовиться. Когда потом прочитал что это такое, долго ругался, ибо часть этих паттернов я применял, но не знал, что они так красиво называются.
Интересную критику дизайн-паттернов можно прочитать здесь. Написано практически «по следам» оригинала от GoF. В общем, формула почти всех дизайн-паттернов — это «как на С++ сделать в два экрана то, что на лиспе делается в пять строк c использованием high-order functions». ООП, с точки зрения дизайн-паттернов, хорошо тем, что таки позволяет это делать: наследование (держа в уме синглетоны) позволяет довольно дёшево эмулировать functions as first-class objects путём создания как бы различных функций, одинаковых по возвращаемому типу и типам параметров (один и тот же метод в разных наследниках одного и того же предка).
Так ведь таких сайтов большинство. А вы сходу сможете назвать сайт, разрабатывать который было бы интересно и приходилось узнавать что-то новое? А что автор делает самое популярное за чудовищно демпинговую цену — ну… развития нет никакого (вот и с ООП не разобрался), зато за месяц выходит зарплата среднего тим-лида — и это всё дома, в спокойной обстановке.
Могу, любой достаточно крупный проект, по сути своей нестандартен, и при его разработке узнаешь что-то новое.
Ну каждый выбирает по себе, я не так уж критиковал, демпинг вечен, всех не переубедишь и не раскритикуешь, я скорее удивлялся, я бы свихнулся 6 лет клепать вот такие вещи. Почему я и посчитал что автор сильно завысил свой опыт.
Ну каждый выбирает по себе, я не так уж критиковал, демпинг вечен, всех не переубедишь и не раскритикуешь, я скорее удивлялся, я бы свихнулся 6 лет клепать вот такие вещи. Почему я и посчитал что автор сильно завысил свой опыт.
Я программирую уже почти 20 лет, на различных языках и в различных парадигмах.
Все это пузырьки на воде, ветер в головах, туман в глазах.
Кто не познал ассемблер — не познал дао.
Все это пузырьки на воде, ветер в головах, туман в глазах.
Кто не познал ассемблер — не познал дао.
Только машкоды, только хардкор.
старая добрая команда M-x butterfly ;)
На всякий случай оставлю ссылку, а то не все ж в Emacs-е пишут :)
Хороший был язык программирования — машкоды или ассемблер для PDP-11…
Вы путаетесь даже в понимании базовых принципов ООП, сложно говорить что вы даже «и не разобрался до конца». Похоже вы понимаете ООП как синтаксически избыточный способ записи кода, который будет работать даже без функций, не говоря о классах и методах.
А ООП, кроме всего прочего, позволяет снизить необходимость «проверять все и вся».
А ООП, кроме всего прочего, позволяет снизить необходимость «проверять все и вся».
А ООП, кроме всего прочего, позволяет так изуродовать код, что потом, копаясь в этих классах, думаешь: «НАХЕРА!»
P.S. Это — очень продуктивный комментарий.
P.S. Это — очень продуктивный комментарий.
Изуродовать при желании код можно кучей способов, например активным использованием goto.
Последнее слово можно поменять на java — смысл не изменится
Что любопытно, принципиальный отказ от использования всех goto-подобных операторов и строгое следование принципам Дейкстры уродуют код столь же эффективно.
Честно, еще ни разу не видел goto приложения, по крайней мере на PHP.
Как раз не пониманием ООП, а так же скверным именованием сущностей, отсутствием документации к методам, и плохим знанием английского — легко все приходит к странно «работающей» структуре. В последствии обычно говорят: «Лучше бы я использовал функции».
Как раз не пониманием ООП, а так же скверным именованием сущностей, отсутствием документации к методам, и плохим знанием английского — легко все приходит к странно «работающей» структуре. В последствии обычно говорят: «Лучше бы я использовал функции».
В «понимании базовых принципов ООП» путаются даже те, кто его хорошо знает и давно применяет. Хорошее подтверждение — постинг "Я не знаю ООП".
извините конешно, но вот так и появляются говнокодеры!
Если за 6 лет Вы не добились никакого прогресса в своей профессии, это сугубо Ваша проблема, и ООП тут не причём совсем!
Если за 6 лет Вы не добились никакого прогресса в своей профессии, это сугубо Ваша проблема, и ООП тут не причём совсем!
Плевать, какое просили качество и сколько платят, но SQL-инъекции непростительны тому кто программирует 6 лет, хоть использует он ООП, хоть нет.
Статья о программировании и без кода? Тут особо нечего обсуждать.
Приведите пример того, что вы писали в любом последнем проекте — сразу будут видны и плюсы вашего подхода и его минусы.
Приведите пример того, что вы писали в любом последнем проекте — сразу будут видны и плюсы вашего подхода и его минусы.
Делает затруднительным использование не значимых характеристик
Если характеристика реального или вымышленного объекта используется в программе, значит она значимая (мы же не пишем специально мёртвый код)?
Можно сделать тоже самое, без использования ООП
Можно писать программы прямо в машинных кодах.
Все что используется и говорится в идеологии, используется и без внедрения ООП
Правильно, ООП инструмент для удобного стандартизированного использования этих принципов.
Внедрение ООП в код, дополнительно тратится от 12% до 75% времени
Источник? И времени чего? Написания уже обдуманного кода, то есть когда время зависит чисто от количества символов в коде, или времени, начиная от постановки задачи и сбора требований до поддержки готового решения?
Что касается инкапсуляции, насколько сложно вывести обрабатывание данных в отдельный файл, не используя классы и функции?
Это не инкапсуляция, а декомпозиция. Просто вынеся часть кода в отдельный файл, типа скрыв реализацию, вы её не скроете, она будет работать в глобальном неймспейсе со всеми вытекающими.
По поводу наследование, это вообще бред, так как вовремя любого программирования это используется. Мы делаем одни действия ради использования результата в других.
Наследование это не использование результатов одних действий в других, это расширение и/или изменение функциональности существующего кода без его изменения. Побочный эффект в некоторых языках — контроль типов.
Перейдем к полиморфизму, да с одной стороны это классно, не приходится отвлекаться на мелочи, не получаешь никакой лишней информации и не можешь использовать ее.
Тут даже возразить нечего, скрытие мелочей — это инкапсуляция, а полиморфизм — это возможность использовать разные реализации с единой спецификацией.
Если характеристика реального или вымышленного объекта используется в программе, значит она значимая (мы же не пишем специально мёртвый код)?
Можно сделать тоже самое, без использования ООП
Можно писать программы прямо в машинных кодах.
Все что используется и говорится в идеологии, используется и без внедрения ООП
Правильно, ООП инструмент для удобного стандартизированного использования этих принципов.
Внедрение ООП в код, дополнительно тратится от 12% до 75% времени
Источник? И времени чего? Написания уже обдуманного кода, то есть когда время зависит чисто от количества символов в коде, или времени, начиная от постановки задачи и сбора требований до поддержки готового решения?
Что касается инкапсуляции, насколько сложно вывести обрабатывание данных в отдельный файл, не используя классы и функции?
Это не инкапсуляция, а декомпозиция. Просто вынеся часть кода в отдельный файл, типа скрыв реализацию, вы её не скроете, она будет работать в глобальном неймспейсе со всеми вытекающими.
По поводу наследование, это вообще бред, так как вовремя любого программирования это используется. Мы делаем одни действия ради использования результата в других.
Наследование это не использование результатов одних действий в других, это расширение и/или изменение функциональности существующего кода без его изменения. Побочный эффект в некоторых языках — контроль типов.
Перейдем к полиморфизму, да с одной стороны это классно, не приходится отвлекаться на мелочи, не получаешь никакой лишней информации и не можешь использовать ее.
Тут даже возразить нечего, скрытие мелочей — это инкапсуляция, а полиморфизм — это возможность использовать разные реализации с единой спецификацией.
Источник? И времени чего? Написания уже обдуманного кода, то есть когда время зависит чисто от количества символов в коде, или времени, начиная от постановки задачи и сбора требований до поддержки готового решения?
По собственному опыту, от получения полного задания, до окончания тестирования(перед правками со стороны клиента).
По собственному опыту, от получения полного задания, до окончания тестирования(перед правками со стороны клиента).
«Похоже вы понимаете ООП как синтаксически избыточный способ записи кода»
Да, именно так я его и понимаю.
Во всем остальном, снимаю шляпу, и говорю что я полный 0-ль в ООП, или точнее вообще в нем не разобрался.
Да, именно так я его и понимаю.
Во всем остальном, снимаю шляпу, и говорю что я полный 0-ль в ООП, или точнее вообще в нем не разобрался.
Оффтоп: меня всегда поражало, как вы развернуто отвечаете.
А по теме: тут и добавить нечего, автор думаю, все понял.
А по теме: тут и добавить нечего, автор думаю, все понял.
Сколько же лишнего кода пишется, не используя например класс для работы с БД. Я не представляю как без ООП можно не повторять один и тот же код.
$sql=«UPDATE `operator` set `status`='$_GET[online]' where `id`=1»;
$table=mysql_query($sql,$db_link);
ну и с пред проверкой типа:
foreach ($_GET as $key=>$value) {
if(($value!='')and($key!='do'))
$_GET[$key]=intval($value);
}
$table=mysql_query($sql,$db_link);
ну и с пред проверкой типа:
foreach ($_GET as $key=>$value) {
if(($value!='')and($key!='do'))
$_GET[$key]=intval($value);
}
Функции. По сути $obj->method() является аналогом obj_method($obj). ООП не средство избежать повторного написания кода, это его побочный эффект как «наследника» структурного программирования.
Правда ваша, не подумал. Но если написать вместо
это не сделает программу прозрачной и гибкой. Мне придется думать о куче ненужных вещей, о который я думать не должен.
$db = new db();
$db->save($object);
require_once('db.php');
dbSave($dataArray);
это не сделает программу прозрачной и гибкой. Мне придется думать о куче ненужных вещей, о который я думать не должен.
Внутри $db уже могут храниться данные, например указатель на сединение с базой.
Для функций эти данные нужно каждый раз предавать в аргументах или использовать глобалсы?
Для функций эти данные нужно каждый раз предавать в аргументах или использовать глобалсы?
Прочитай книгу «паттерны проектирования» — хорошая штука.
fastchange.com.ua… время разработки 4,5 часа.
watchcases.ru, magniflex.ru/shop/, xpectik.com.ua… первая разработка 16-17 часов, последующие до 6,5 часов.
Так а что тут удивительного? То, что называют «говнокодом», обычно пишется намного быстрее, чем нормальный ООП-код (если бы грамотный ООП-код, разбитый по классам и с использованием шаблонов проектирования писался быстрее, «говнокод» бы никто не писал вообще). А вот если программист, которому этот код надо будет поддерживать, или менять, или добавлять новые возможности, увидит код наподобие
foreach($row=mysql_fetch_assoc($mysqlResult))
echo "<td>".htmlspecialchars($row['name'])."</td>";
да еще и раскиданный по сотне мест проекта, то радости у него будет мало. И, кстати, лучше, чтобы он не знал, где вы живете :). И учтите еще:
Внедрение ООП в код, дополнительно тратится от 12% до 75% времени
Правда, на ООП тратится много времени при разработке. Теперь вспомните, что разработка обычно занимает около 20% жизненного цикла проекта, а части и меньше того, и пересчитайте заново.
Правда, на ООП тратится много времени при разработке.
Я бы сказал при проектировании, при собственно кодировании потери времени минимальны.
Я бы сказал при проектировании, при собственно кодировании потери времени минимальны.
разработка = проектирование + кодирование + отладка
На таких мелких проектах и в таком «стиле» кодирование и впрямь занимает основное время (всего проектирования — набросать порядок копипасты да может быть карту сайта на флипчарт накидать). А если такой код сначала написать, а затем уже приводить к ООП (не могу иначе понять слово «внедрение ООП в код»), то потери все же станут значимыми.
Впрочем, это все меркнет по сравнению с усилиями, которые придется прикладывать для поддержки таких проектов.
На таких мелких проектах и в таком «стиле» кодирование и впрямь занимает основное время (всего проектирования — набросать порядок копипасты да может быть карту сайта на флипчарт накидать). А если такой код сначала написать, а затем уже приводить к ООП (не могу иначе понять слово «внедрение ООП в код»), то потери все же станут значимыми.
Впрочем, это все меркнет по сравнению с усилиями, которые придется прикладывать для поддержки таких проектов.
Никто не будет, думаю, «поддерживать» код, написанный за 200 баксов. Просто денег на найм «суппортера» не планируется. Есличо, выкинут и перепишут.
Итак, снимаем покровы с заголовка
> Почему все работают с ООП?
Видно вокруг одни идиоты, а вы в зоне комфорта зашибаете неплохую деньгу за 15-20 сайтов в месяц. Но это мало, как говорил Остап:
> Бросьте свои масляные краски. Переходите на мозаику из гаек, костылей и винтиков.
Даешь 30 сайтов в месяц! :)
Но — все это чепуха по сравнению с тем, что я видел в Москве. Там один художник сделал картину из волос. Большую картину со многими фигурами, заметьте, идеологически выдержанную, хотя художник и пользовался волосами беспартийных, — был такой грех. Но идеологически, повторяю, картина была замечательно выдержана.
Называлась она «Дед Пахом и трактор в ночном». Это была такая строптивая картина, что с ней просто не знали, что делать.
Иногда волосы на ней вставали дыбом. А в один прекрасный день она совершенно поседела, и от деда Пахома с его трактором не осталось и следа. Но художник успел отхватить за выдумку тысячи полторы.
> Почему все работают с ООП?
Видно вокруг одни идиоты, а вы в зоне комфорта зашибаете неплохую деньгу за 15-20 сайтов в месяц. Но это мало, как говорил Остап:
> Бросьте свои масляные краски. Переходите на мозаику из гаек, костылей и винтиков.
Даешь 30 сайтов в месяц! :)
Но — все это чепуха по сравнению с тем, что я видел в Москве. Там один художник сделал картину из волос. Большую картину со многими фигурами, заметьте, идеологически выдержанную, хотя художник и пользовался волосами беспартийных, — был такой грех. Но идеологически, повторяю, картина была замечательно выдержана.
Называлась она «Дед Пахом и трактор в ночном». Это была такая строптивая картина, что с ней просто не знали, что делать.
Иногда волосы на ней вставали дыбом. А в один прекрасный день она совершенно поседела, и от деда Пахома с его трактором не осталось и следа. Но художник успел отхватить за выдумку тысячи полторы.
Больше всего удивляет меня в людях воинствующее невежество, потому не могу пройти мимо.
Автор за 6 лет не понял что это такое Абстракция, Инкапсуляция, Наследование, Полиморфизм и ООП (выше более терпеливые комментаторы уже объяснили подробно про каждый пункт). И теперь он пытается оправдать свое незнание смешными нападками на эти явления. На самом деле лишь обнажая свое дилетантство.
По долгу службы регулярно провожу собеседования разработчиков. Иногда попадаются персонажи, не знающие принципов и паттернов проектирования, но при этом их критикующие. Не читающие книг и незнающие особенностей языка, потому что «в работе это не нужно». Про себя смеюсь, а ребят таких отправляю домой.
Решать бизнес-задачи — это хорошо. Тяп-ляп на коленке, но ведь работает! Главное, что работает.
Но ребята, вам самим не стыдно за свой «профессиональный» уровень? Вам нравится делать говно? Вы не любите свою работу? Не хотите быть лучше?
Автор за 6 лет не понял что это такое Абстракция, Инкапсуляция, Наследование, Полиморфизм и ООП (выше более терпеливые комментаторы уже объяснили подробно про каждый пункт). И теперь он пытается оправдать свое незнание смешными нападками на эти явления. На самом деле лишь обнажая свое дилетантство.
По долгу службы регулярно провожу собеседования разработчиков. Иногда попадаются персонажи, не знающие принципов и паттернов проектирования, но при этом их критикующие. Не читающие книг и незнающие особенностей языка, потому что «в работе это не нужно». Про себя смеюсь, а ребят таких отправляю домой.
Решать бизнес-задачи — это хорошо. Тяп-ляп на коленке, но ведь работает! Главное, что работает.
Но ребята, вам самим не стыдно за свой «профессиональный» уровень? Вам нравится делать говно? Вы не любите свою работу? Не хотите быть лучше?
Вот какие посты должен писать человек, осознающий уровень своего незнания:
habrahabr.ru/post/144729
Честно и без понтов.
habrahabr.ru/post/144729
Честно и без понтов.
1. Пост, который вы привели — ни о чем (при всем уважении к автору).
2. Говно, простите, делают все.
3. Пост, который мы комментируем — непродуктивен.
2. Говно, простите, делают все.
3. Пост, который мы комментируем — непродуктивен.
Думаю, правильный ответ — «говно-ПМ-любитель». Т.к. сам ставит задачи и получает деньги — то всё-таки ПМ, и сравнивать надо с ПМами. А по сравнению с нормальными ПМ — уровень очевиден.
Тут ещё что — если ПМ сам себе продавец и сам пишет код, то может позволить себе говнокодить.
Такой «универсал-совместитель» — тупиковый вариант как с качестве программиста, так и в качестве ПМа.
Тут ещё что — если ПМ сам себе продавец и сам пишет код, то может позволить себе говнокодить.
Такой «универсал-совместитель» — тупиковый вариант как с качестве программиста, так и в качестве ПМа.
Изготовление сайтов — это периферия программирования, как вообще на этих примерах можно делать какие-то философские выводы?
Автор, своими аргументами и разоблачающим описанием всех недостатков ООП, вы достучались до моего сердца и буквально открыли глаза на истинное положение дел. В вас виден истинный знаток дела, четко понимающий положение дел в области программирования в целом и разработки веб-проектов в частности. Вы настоящий профессионал! Ведь не каждый сможет делать по 10-15 проектов в месяц. Это просто невероятно.
Наша команда разработчиков с нетерпением будет ждать от вас новой разгромной статьи, которая направит на путь истинный заблудшие души программистов. Спасибо вам!
Наша команда разработчиков с нетерпением будет ждать от вас новой разгромной статьи, которая направит на путь истинный заблудшие души программистов. Спасибо вам!
а ещё мы очень заинтересованы в Вашем профессионализме и хотим предложить вам работу с зарплатой в 5-7k$. Хотя с такими знаниями и навыками Вам стоит попробовать устроится в гугл.
Зачем?)))
В гугле вам будет скучно — не получится делать 30 сайтов в месяц…
Возможно, но профиль я себе немножко другой взял)
Сидишь, программируешь, не паришься, деньги сшибаешь. + остается время на другие сферы.
Сидишь, программируешь, не паришься, деньги сшибаешь. + остается время на другие сферы.
10-15 сайтов в месяц и еще время на другие сферы? Я вам завидую.
да вы батенька, извиняюсь за выражение, задрот :)
fastchange.com.ua в ресурсе огромная масса кросс-серверной и кросс — сайтовой работы, сам по себе явлется просто оболочкой для пользователя, и генератором отчетности для владельца, применение ООП только от API Яндекса, время разработки 4,5 часа.
watchcases.ru, magniflex.ru/shop/, xpectik.com.ua раньше стояли на системе OsCommerce, который «насквозь пропитан» ООП, теперь на системе, которую я разработал, без единого элемента ООП, скорость загрузки сайта выросла от 1200% до 3600%, первая разработка 16-17 часов, последующие до 6,5 часов.
— Это правда, что вы печатаете со скоростью 1000 знаков в минуту?
— Правда! Вот только такая фигня получается…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему все работают с ООП? Кратко о главном или «пища» для размышления