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

Не могу с этим согласиться. Паттерны строго обязательно изучать, без них ООП, с моей точки зрения, неполноценно. Самое смешное до некоторых, в конце-концов, дойдешь сам, но они от этого не перестанут быть паттернами. Паттерн и бест-практика почти синонимы. Зачем самому изобретать велосипед, когда можно посмотреть чертежи, сэкономить себе кучу времени? Ты от этого разве хуже поймешь принцип велосипеда, что у него педали, цепь, руль? Конечно же нет, только сэкономишь время. Исключительно на своём опыте учатся лишь дураки и маленькие дети. Чтобы построить лучше, как минимум, необходимо знать какие уже существуют. Или нет? =)

Любые редкоиспользуемые приемы в ИТ быстро забываются. Совершенно не говорит, что они не нужны вовсе. Попробуй полгодика не садиться за комп. Да что полгодика, через пару месяцев придешь и обалдеешь сколько всего забыл. Хотя пользовался почти каждый день! Что ж получается, тебе ИТ не нужно?

При том что все перечисленные мной антипаттерны относятся к ООП.

Вообще подозреваю ТС пришел не ради наших холиваров. Захотел изучать ООП, может он на Java хочет свичнуться! =)

Рон использует готовое, экономит время, спит.
Твин уже давно обжился всем своим, теперь много времени, спит)

_____________
Промокод предоставляет скидку на заказ домена и/или хостинга reg.ru
BFCC-3895-8804-9ED2

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

Не обольщайся, не повзрослел ты. Тебе просто дали порулить папиной машиной. Ну если ты только не пишешь на прикладных языках. А в PHP так и есть. Это как на даче у меня. Можно в ларек за сигаретами на велосипеде сгонять. А можно на машине. Только на велике проще, быстрее (по закоулкам) и экономичнее. Но нет, мы же взрослые, нам не пристало, мы на машине поедем. И всем скажем - это круто, это новые технологии, водитель с правами ценится выше, чем велосипедист. Ведь в город все на машинах едут!

А на то, что результат один и тот же - пачка сигарет, на это наплевать. Вам важен процесс, а не результат. Важно, что есть целая куча заготовок - ДВС, трансмиссия, навигатор и крутой аудиоцентр со свистопирделками. Это так по взрослому!

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

Так и с паттернами в ООП. Есть несколько популярных и часто применяющихся. И вполне этого достаточно. Про остальные хватит помнить того, что они существуют. Что я когда то издалека тыкал их веточкой. Потому что они скорее всего вообще мне не понадобятся, ибо разработаны, повторюсь, для разруливания монолитного дерьма. Вернее они разработаны для десктопа, где от монолита уйти трудно. А вот в PHP он не нужен по определению.

Но и не только. Вообще этот твой совет похож на такой:

Как будто без ООП можно писать как попало.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Я и посоветовал осторожнее. Иначе получится очередной фанатик типа тебя или chee. А к чьему совету ему прслушаться, дело сугубо ТС. Главное плюрализм. Изучать конечно надо. И паттерны посмотреть обязательно надо. Хотя бы для того, чтобы знать, где их применять не нужно. Но положить на них жизнь, как некоторые, я бы не советовал. Методологий много, нужно уметь все использовать, каждую на своем месте. И вперемешку тоже. Это мультипарадигма, двигатель прогресса. Упереться в что то одно, в ООП в частности, это добровольная кастрация.

По поводу Java, да вроде нет:

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Сильное заявление проверять я его конечно не буду

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

Это прозвучало примерно: "зачем мне изучать СНИПы, они нужны для возведения монолитных многоэтажек, а я строю деревянный дачный домик". Или еще: "зачем учить расцветку, пускай ее учат жэковские электрики, а я положу такими цветами, какими мне удобно".

Какая разница сколько и как живет процесс, ООП не для машины придумано, а для человека. Если конкретно ты находишь такой подход (или паттерн) неудобным, то не используй. Но абсолютное большинство программистов думают иначе. Даже больше того, уходят из PHP в другие, более объектно-ориентированные ЯП.

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

С той лишь разницей, что паттерны это не приципы, скорее алгоритмы, которые забываются быстрее всего. В курле не содержится никаких алгоритмов, там даже принципа своего нет, просто отражение протокола HTTP и всё. Точно такой же АПИ как и реализация работы с другими внешними ресурсами (MySQL, GD, you name it)

Жизнь положить? Полчаса раз в 2 месяца, а то и реже, на то, чтобы освежить набор паттернов по схемам UML, это целая жизнь? )))) Смешно даже.

Вот кстати совет ТСу, выучить UML, он упростит поставленные цели.

Ну кто ж признается что хочет слезть с PHP на форуме PHP?

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

Неоторые процессы запускаются достаточно долго и надсадно. Запускать их тогда, когда в них возникает необходимость, бывает довольно расточительно, их лучше запустить один раз и забыть. Потому и делаются монолиты, которые да, гораздо удобнее писать на ООП. Но это в десктопе! В том же PHP все совершенно не так, и даже с точностью наоборот. Процессы должны быть как можно меньше и экономичнее. А значит монолит тут противовоказан. Соответственно нет никакой необхдимости в огромной куче специфических паттернов, а зачастую и ООП в целом.

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

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

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

Да и пусть забываются, раз не используются вовсе.

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.