весь топ страницы топик про ООП. или у меня двоиться уже.
и я не правильно понял пост наверху.
там как раз написано
Полная Версия: Открытая разработка проекта MIRA
| Цитата |
| Я знаю много отличных приложений написанных не основываясь на паттернах программирования |
с этим я согласен.
всмысле - что паттерны это паттерны, но не как закономерная обязательная составляющая ооп.
_____________
HTML, CSS (Bootstrap), JS(JQuery, ExtJS), PHP, MySQL, MSSql, Posgres, (TSql, BI OLAP, MDX), Mongo, Git, SVN, CodeIgnater, Symfony, Yii 2, JiRA, Redmine, Bitbucket, Composer, Rabbit MQ, Amazon (SQS, S3, Transcribe), Docker
Паттерны это лишь способы решить задачи, они просто описывают "абстрактную" проблему и метод ее решения. Это как та же теорема Пифагора (как способ найти длину гипотинузы) или тангенс (точнее обратный тангенс tan^-1) что бы найти угол между двумя точками (x1, y1 и x2, y2). Решить проблему можно и без паттернов (но все равно неосмысленно можно воспользоваться паттерном).
Я бы сказал, что решение задач с помощью (паттернов vs SOLID) + ООП или других вариантов это тоже самое что выводить echo vs print. Оба похоже, только оба имеют разный синтаксис (echo через , можно, а print возвращает int(1)), так же и паттерны, можно юзать паттерн стратегию или же написать что то хитрое следуя принципам SOLID (но на каком то уровне это будет тоже паттерном).
Паттерны бывают не только в ООП и с классами. Вот вам пример паттерна в webdev'е: Пагинация. Разве это не паттерн? По моему да к это один из паттернов веб разработки. Пагинация сама по себе это лишь элемент GUI, но без логики этот GUI элемент нафиг никому не нужен.
Как бэ pattern – "a combination of qualities, acts, tendencies, etc., forming a consistent or characteristic arrangement".
Так что паттерн можно хоть назвать echo и print
Т.к. они повторяются очень часто.
Давайте в следующий раз делать акцент не на просто "паттернах", а на software design паттернах.
P.S.: Если чего, я продолжаю работу, так что не надо говорить "слив" и т.д.
_____________
Мой блог
Я бы сказал, что решение задач с помощью (паттернов vs SOLID) + ООП или других вариантов это тоже самое что выводить echo vs print. Оба похоже, только оба имеют разный синтаксис (echo через , можно, а print возвращает int(1)), так же и паттерны, можно юзать паттерн стратегию или же написать что то хитрое следуя принципам SOLID (но на каком то уровне это будет тоже паттерном).
Паттерны бывают не только в ООП и с классами. Вот вам пример паттерна в webdev'е: Пагинация. Разве это не паттерн? По моему да к это один из паттернов веб разработки. Пагинация сама по себе это лишь элемент GUI, но без логики этот GUI элемент нафиг никому не нужен.
Как бэ pattern – "a combination of qualities, acts, tendencies, etc., forming a consistent or characteristic arrangement".
На русском
Комбинация свойств, поступков, тенденций, и т.д., формирующее постоянное характерное расположение
Так что паттерн можно хоть назвать echo и print
Т.к. они повторяются очень часто.
Давайте в следующий раз делать акцент не на просто "паттернах", а на software design паттернах.
P.S.: Если чего, я продолжаю работу, так что не надо говорить "слив" и т.д.
Мысль о которой стоит подумать
P.S.S.: А вообще кому нужен этот срач про Паттерны vs "не шаблонное мышление"?
Сам по себе человек склонен к шаблонному мышлению и поступкам: работать -> жрать -> срать -> спать
Разве это не шаблонно? Человек сам почти весь построен на шаблонах.
Сам по себе человек склонен к шаблонному мышлению и поступкам: работать -> жрать -> срать -> спать
Разве это не шаблонно? Человек сам почти весь построен на шаблонах.
_____________
Мой блог
| Цитата |
С той же стратегией. А кто сказал, что нужно "допиливать код"? Вы просто не знаете, как можно сделать иначе, так как мыслите только шаблонами. Мне никто не запретит так же написать статические классы под каждую сеть, которые будут выдавать определенный набор данных и соединить их где то в одном месте. Можете это назвать стратегией, дело хозяйское, однако такой подход не вписывается в вашу доктрину. |
Конечно сделать можно иначе, например, как вы предложили. Только это не стратегия, вы нарушаете OCP вот здесь "и соединить их где то в одном месте". Вы полезете в код, будете там что-то править и дописывать. А суть стратегии как раз в том, чтобы обеспечить взаимозаменяемость, без всяких там "соединить их где-то в одном месте".
Вас как раз и будет отличать то, что вы с мешаниной из процедурного и оо-программирования, только сами сможете разобраться, что вы там напрограммировали. Другому программисту будет сложно разбираться, потому что, чтобы добавить что-то, ему нужно еще и "соединить их где то в одном месте".
Да, возможно вы быстрее напишите приложение, да возможно оно будет потреблять меньше памяти. Но оно будет совершенно не поддерживаемое в дальнейшем и не масштабируемо, потому что, когда вы его писали, совершенно не озаботились архитектурой. Так пишут только прототипы, чтобы быстро показать результат. А затем выбрасывают и пишут заново, уже нормально.
Вы пишите, что просто переросли ооп, что у вас новый супер-уровень, а мы все не познали дзен. Но тогда расскажите нам о своем оо-опыте, расскажите о паттернах, которые вы использовали в процессе оо-программирования. Знаете ли вы все основные паттерны проектирования ? Где и как вы их применяли? Есть ли ваши проекты на гитхаб? И если нет и никогда не применяли, как вы тогда можете утверждать, что вы напишите даже в разы лучше всё, чем со всеми этими паттернами, если никогда не писали оо-код с их использованием.
Потому что, сейчас складывается немного другое впечатление. Это уровень когда, чтобы развивать проект дальше, нужно "вечно" что-то дописывать в уже готовом коде и юнит-тесты уже не запускались 10 раз подряд, потому что там "что-то падает".
| Цитата |
Вам приходилось работать под большим трафиком? Несколько десятков посетителей в секунду? Допустим прошел рефакторинг. Нужно тупо поменять на боевом сайте десяток файлов. Помним, что один файл валит всю систему. Разраб начал заливать их - сайт упал. |
И еще вот здесь. Впринципе, мне всё понятно. Видимо вы не вкурсе, как вообще происходит деплой и выкатка новой версии проекта. Никто "тупо" на боевом сайте не меняет десяток файлов. В простейшем случае, это может быть shell-скрипт, который обновит по сервера, сходит в git, склонирует оттуда новую версию проекта, положит её в новую директорию на сервере, подтянет зависимости с помощью композера, накатит миграции в бд, прогонит тесты и если всё прошло успешно, то переключит симлинк со старой версии проекта на новую. Пользователь даже ничего не заметит. И уж тем более сайт не упадет. Если деплой и выкатку нужно делать сразу на много бекенд-серверов, то можно взять какое-нибудь готовое решение или свое дописать. Во времена, когда композера еще не существовало, деплой проекта делали deb-пакетом, если были зависимости в проекте.
А вы я так понял ftp-юзаете?
Здесь расположена полная версия этой страницы.