@BarneyGumble
Давно использую PHP в работе, но никогда не писал самостоятельно что-то по-настоящему серьёзное. Знаю основы ООП, знаю концепции MVC, понимаю как работают популярные фреймворки типа Yii и Laravel и даже часто на них делаю какие-то проекты. Но вот если мне поставить задачу написать какой-нибудь парсер или систему анализа данных, я её напишу, но это будет куча говнокода, работающего, но абсолютно не расширяемого в дальнейшем. Потому что, как читать использовать ООП-код я знаю, а вот как проектировать и писать его — к сожалению, нет. Зачастую, если встречается какая-то задача, я пишу кучу функций в процедурном стиле, где много чего дублируется и…хорошо, что работает вообще.
Возможно, кто-нибудь встречал какие-то книги или курсы, где показывалась бы разница при решении задач между процедурным кодом и ООП? Хочется на конкретных примерах почуствовать, почему соорудить некий интерфейс и классы с методами будет проще и оптимальнее, чем в тысячный раз говнокодить? В сети много информации, разжёвывающих саму суть ООП с её инкапсуляциями и полиморфизмом, но вот конкретных примеров, почему писать, как я сейчас пишу, это малоэффективно, и что надо изменить в своей голове, чтобы перестать начинать решать задачу с написания очередной функции, — я практически не встречал. Возможно, встречали вы…
Решения вопроса 2
@glaphire
Мне в свое время помогла проработка всех шаблонов проектирования из трех источников: «Head First Design Patterns«+refactoring.guru+designpatternsphp.readthedocs.io. Каждый шаблон разбирала и пыталась понять, почему здесь нужен паттерн, а не процедурный код, обернутый в один класс. Еще помогла книга по чистой архитектуре, но она зашла уже после паттернов. Просто важно полностью для себя понять, почему эти подходы до сих пор существуют и находить для себя два-три примера, потому что один-единственный пример для изучения может быть однобоким и даже неправильным.
Также эти книги и темы помогают вылечиться от трудностей решения задач на фреймворках, потому что наконец-то начинаешь видеть всю структуру и взаимодействия модулей и классов, а не просто примеры из документации натягиваешь на бизнес-требования)
Также эти книги и темы помогают вылечиться от трудностей решения задач на фреймворках, потому что наконец-то начинаешь видеть всю структуру и взаимодействия модулей и классов, а не просто примеры из документации натягиваешь на бизнес-требования)
3
комментария
Ответы на вопрос 2
@Kirill-Gorelov
Эх дружище, так я тебя понимаю……
Но сколько бы я сам книг не прочитал, курсов не пересмотрел, тут дело в одной штуке, опыт.
Который приходит только через боль, пот, мучения, стыд, страдания, несколько лет ужасного кода и потом будет приходить видение как сделать классно и правильно, потому что пока ты все это на себе испытаешь ты очень многому научишься.
Поэтому продолжай читать, писать, учиться и все придет само собой.
Но сколько бы я сам книг не прочитал, курсов не пересмотрел, тут дело в одной штуке, опыт.
Который приходит только через боль, пот, мучения, стыд, страдания, несколько лет ужасного кода и потом будет приходить видение как сделать классно и правильно, потому что пока ты все это на себе испытаешь ты очень многому научишься.
Поэтому продолжай читать, писать, учиться и все придет само собой.
@DollyPapper
Их не нужно сравнивать. Эти подходы дополняют друг друга. Внутри методов класса ты как ни крути пишешь процедурный код.