Паттерны проектирования?

Перечитал большое кол-во статей про паттерны и их использование в php, но так и не понял зачем их используют в приводимых примерах, и после прочтения очередной статьи у меня остается единственный вопрос "зачем?", также очень часто в разных статьях примеры не имеют между собой ничего общего, это меня выводит из себя больше всего. Даже не знаю что делать, и как дальше жить. Посоветуйте может книжки какие, где не просто показаны какие-то абстрактные примеры, а объясняются больше ситуации, где эти чертовы шаблоны можно применить.

Пока-что для меня паттерны - это код, который усложнен just for lulz.

P.S. У вас есть возможность предотвратить суицид незадачливого программиста.
  • Вопрос задан
  • 4272 просмотра
Решения вопроса 1
@vkdv
Паттерны - это реальные инструменты, позволяющие добиться реализации концепции объектно-ориентированного проектирования и принципов SOLID

Ссылка на SOLID

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

Один из наиболее часто встречающихся мне примеров, это пример принципа "Принцип открытости/закрытости" , когда класс - описывающий некую сущность(например модель комментария) , описывает только свои базовые назначения( создание, удаление, редактирование), при этом такие механизмы, как модерация, прикрепление файлов, лайки , реализуется другими классами и "прикручиваются" к классу моделей через интерфейсы и наследование/ трейты / примеси

При этом :
1) Никак не изменяется код класса "Комментарий" (кроме подключения интерфейса) и в будущем мы добавляем поведения без изменения класса + стабильность системы, гибкость
2) Каждый класс имеет свое четкое назначение + легкость модификации, порядок
3) Комментарии наследуют некоторое поведение, путем подключения поведения, но также могут поступать любые другие классы - сущности (посты, блоги итп) , то есть интерфейс и реализация лайков универсальна, и весь функционал работы лайков находится только (строго!!!) в одном месте + легкость модификации, Универсальность, стабильность, интуитивная понятность

Из википедии :

Признаки плохого проекта
Закрепощённость: система с трудом поддается изменениям, поскольку любое минимальное изменение вызывает эффект "снежного кома", затрагивающего другие компоненты системы.
Неустойчивость: в результате осуществляемых изменений система разрушается в тех местах, которые не имеют прямого отношения к непосредственно изменяемому компоненту.
Неподвижность: достаточно трудно разделить систему на компоненты, которые могли бы повторно использоваться в других системах.
Вязкость: сделать что-то правильно намного сложнее, чем выполнить какие-либо некорректные действия.
Неоправданная сложность: проект включает инфраструктуру, применение которой не влечёт непосредственной выгоды.
Неопределенность: проект трудно читать и понимать. Недостаточно четко выражено содержимое проекта.

Оттуда же про SOLID

Избавиться от "признаков плохого проекта"[4] помогают следующие пять принципов SOLID:

Принцип единственной ответственности (The Single Responsibility Principle)
Существует лишь одна причина, приводящая к появлению класса.

Принцип открытости/закрытости (The Open Closed Principle)
«программные сущности … должны быть открыты для расширения, но закрыты для модификации.»

Принцип подстановки Барбары Лисков (The Liskov Substitution Principle)
«объекты в программе должны быть заменяемыми на экземпляры их подтипов без изменения правильности выполнения программы.»

Принцип разделения интерфейса (The Interface Segregation Principle)
«много интерфейсов, специально предназначенных для клиентов, лучше, чем один интерфейс общего назначения.»

Принцип инверсии зависимостей (The Dependency Inversion Principle)
«Зависимость на Абстракциях. Нет зависимости на что-то конкретное.»
Ответ написан
Пригласить эксперта
Ответы на вопрос 11
Смысл в том, что общаются 2 разработчика (один новый в команду пришёл) и он такой спрашивает: а как одна часть системы узнаёт о новых пользователях? Другой говорит: мы там Observer сделали и разработчик не видя ещё код уже приблизительно понимает как всё работает! Потому что он знает как работает паттерн Observer.
Другое дело что сам паттерн бывает спорный и непонятно выгоду получили от него или нет, но это уже другой вопрос...
Ответ написан
Комментировать
GavriKos
@GavriKos
Использование паттернов делает код более структурным. И более понятным другому программисту, знакомому с теми же паттернами. Т.е. не надо будет думать "где же заныкали метод бла-бла-бла", если все подчинено общей логике какого то паттерна.
Дополнительно возможно (зависит от паттерна) добавляются всякие плюшки типа облегчения добавления нового функционала.
Ответ написан
AlexXYZ
@AlexXYZ
O Keep Clear O
Самый важный ресурс - время. Паттерны могут его экономить. А могут и наоборот. Тут все зависит от опыта. Вы их можете сами придумать, когда обнаруживаете в своей жизни определенные последовательности действий. Тут дело не только в программировании. Иногда паттерн можно изменить под свои нужды. Просто это некий шаблон, накрученный на предметную область.
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev
software engineer
Паттерны - это не код. Паттерны - это идея. А код (реализация) может быть разной. Поэтому везде, где вы видите код - это частный пример паттерна.
Ответ написан
Комментировать
GreyCrew
@GreyCrew
Full-stack developer
Сам сейчас активно изучаю данную тему.

Раз проблема с самим пониманием, зачем они нужны, то могу посоветовать поработать с командой разработчиков (>3 person) над каким либо крупным, постояноо развивающимся проектом, тогда понимание надобности объектного проектирования к тебе само придет, когда вы начнете утопать в неподдерживаемом коде. Большинство фреймворков кстате в коробке предлагают вариант реализации.

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

Именно поэтому бессмысленны "небольшие примеры паттернов" - они не играют в небольшом коде.
И так же бессмысленно обсуждать реализацию конкретных классов, связанных между собой паттерном. Она может быть произвольной, лишь бы наружу не торчало лишнего.
Ответ написан
Комментировать
zualex
@zualex
Senior Software Engineer
Вот видео в тему: https://www.youtube.com/watch?v=wX6BBaQZpzE
Паттерны ты уже используешь осознанно или неосознанно.
Паттерны это что то естественное, есть конкретная ситуация, есть конкретный прием решения этой ситуации
Ответ написан
Комментировать
@red-barbarian
изучая паттерны, нужно понимать, что они могут упростить систему, а могут загадить так что никто не поймет.)
вообще цель разбить систему на части, сделать все максимально просто, и части сделать максимально независимо.
обычная болезнь после изучения шаблона - пихать его везде. иногда это получается как пушкой по воробьям.
паттерны это вещь не сама по себе. они иногда нужны для реализации например solid принципов.
Ответ написан
Комментировать
@semki096
С паттернами я столкнулся изучая Symfony. И становится понятно как они работают и какую задачу решают.
Ответ написан
Комментировать
@ghaur
Посоветуйте может книжки какие

По поводу книжек, по моему довольно хорошо разные паттерны объясняет Мэтт Зандстра в "PHP: объекты, шаблоны и методики программирования. 4-е издание"

Если не читали, то можете попробовать. Он там описывает как паттерны от знаменитой банды 4-х, так и шаблоны корпоративных приложений.
Ответ написан
Комментировать
iCoderXXI
@iCoderXXI
React.JS/FrontEnd engineer
Паттерны - это опыт боли, страданий и пота огромного количества лучших разработчиков, и программистов. Можно сказать, что паттерны, как и правила дорожного движения - в некотором роде написаны кровью.

На малых и даже средних по сложности и объёму кода проектах, тем более если пилишь в одного, большинство паттернов будут неочевидны, где-то даже неполезны. Другое дело большой, живущий десятилетиями, энтерпрайз проект, на котором неслабая текучка кадров. Такие монструозные штуки просто невозможно строить без паттернов. Собственно оттуда и повыходили в большинстве своём паттерны.

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

А так, сам на сам, да на мелочи, это баловство и несерьезно.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы