madmages
@madmages
Человек прямоходящий

Где найти паттерны «правильных» частей системы?

Вопрос звучит тупо, но попробую разложить.

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

Вот проектируя большой проект с нуля ты уже оперируешь не паттерновыми объектами а частами систем, которые состоят из паттерновых объектов. К примеру много где нужна авторизация, права доступа, работа с сущностями(редактирование товаров, категорий в админке и т д). Все это в большинстве проектов это в общей сложности очень однотипно, тоесть одно решение пригодилось бы и тут и там и еще много где. Так люди дошли до RBAC, или если нужна авторизация пользователя без получения пароля то тут сгодится OAuth , ну а для логирования почти на все случаи жизни сгодится PSR-3(для пхп)
По своей сути это принципы подсистем в одной большой системе, что то вроде best practice.

Собственно вопрос: существует ли сборник всех этих лучших практик?
  • Вопрос задан
  • 1306 просмотров
Решения вопроса 1
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
Вот проектируя большой проект с нуля ты уже оперируешь не паттерновыми объектами а частами систем


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

Большие проекты начинают проектировать с более высокого уровня. Сначала принимают решение о том, какое разделение на слои у нас будет (для проектов со сроками жизни ~10+ лет имеет смысл позагоняться и вводить гексагональную архитектуру, для проектов со сроками жизни <= строк поддержки фреймворка можно не сильно париться), какие компоненты можно выделить, а уже потом дробить эти большие компоненты на компоненты поменьше.

Затем уже приступать к проектированию каждого отдельного компонента на уровне классов.

Так же если у нас сложная предметная область - проектируют модель предметной области. Обычно тут "паттерны" сами собой получаются тупо при снижении связанности между объектами.

> Собственно вопрос: существует ли сборник всех этих лучших практик?

вне контекста не бывает лучших практик, есть просто практики. В этом плане можно например Фаулера почитать, он очень качественно описывает практики, их плюсы и минусы.

В целом же я бы рекомендовал вам познакомиться поближе с принципами SOLID и GRASP. Последнее мало кто знает, но понимание, например, что такое высокое зацепление, сильно влияет на то, как вы будете проектировать систему.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
index0h
@index0h
PHP, Golang. https://github.com/index0h
Вы ищите то, чего нет. Нет понятия "правильных" частей системы, или "правильных" паттернов.
Вот вам пример: OAuth, что вы привели имеет 2 версии, это что получается, первая была не правильная?))
RBAC - это подход, который далеко не всегда уместен, часто его проще и лучше заменить ACL (безусловно, это не всегда так).

PSR-3 - это не совсем паттерн, это скорее рекомендуемое соглашение.

Конкретно по php миру: рекомендую реализовывать следующие требования, проникнуться Symfony way, активно использовать паттерны: DTO, VO, код писать вместе с тестами (вот это капец как критично для крупных систем).

Что касается более высокоуровневых паттернов, в стиле OAuth, RBAC - они вам потребуются только в случае, если это требуется бизнесу, для которого вы пишете систему.
Ответ написан
Ваш ответ на вопрос

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

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