anton_reut
@anton_reut
Начинающий веб-разработчик

Как вы проектируете классы в ООП и их взаимодействие?

Предположим у вас есть ТЗ на некий проект, и по уму надо сначала Спроектировать все необходимые классы перед тем как начать кодить, что-бы не придумывать ничего "на лету" и не накосячить (что может привести в архитектурный тупик и переделку Всего).
Так вот - в чем вы обычно проектируете? На бумажке (как я :)), в каких-то специальных программах которые создают UML-диаграммы или просто " в уме"?
Под проектированием я понимаю именно связи "вот этот класс делает это и это, потом берет другой класс и делает с помощью него еще и это. Либо это класс-сервис который сам куда-то передается классу-клиенту и что-то должен делать, и так далее.
  • Вопрос задан
  • 1134 просмотра
Пригласить эксперта
Ответы на вопрос 5
@xfg
В PHP сообществе вообще не развиты вопросы проектирования и архитектуры. Большинство лепит, что придумает. PHP изначально родился для примитивных homepage, вобрал в себя всю несерьезность, низкий порог входа и как следствие довольно слабое комьюнити, что часто становится объектом для шуток.

Искать ответы на вопросы проектирования и архитектуры нужно в Java. Например там почти каждый с самых азов слышал о де факто ставшей стандартом слоистой архитектуре, она же layered architecture, она же n-tier architecture и видел изображение похожее на это
main-qimg-91d7188a63a833488f92239028d0ae
Из которой нужно понять, что всю программу можно разделить на несколько слоев и зависимость между слоями должна быть направлена сверху вниз, но не наоборот. Таким образом, например фреймворк может быть инкапсулирован в presentation слой и в любой момент безболезненно заменен на другой, так как другие слои ничего о нем не знают. Вся бизнес-логика инкапсулирована в domain слой в виде plain old java object, который не зависит вообще не от чего, а также предоставляет интерфейсы (репозиториев например) для инфраструктурного слоя и только в этом слое фактически и будет тот самый настоящий ООП, который все так упорно пытаются найти. Никакого стороннего кода в бизнес-логике нет, а соответственно весь сторонний код можно в любой момент поменять, не трогая бизнес-логику вообще.

Для этого нужно открыть какую-нибудь книгу, где за руку проведут с нуля до конкретного приложения построенного с использованием этой архитектуры. Например Implementing domain-driven design, хоть эта книга и о DDD, но я уже говорил, что слоистая архитектура это де факто. С опытом, будет понятно, что в более простых приложениях количество слоев можно уменьшить, понимая на какой компромисс придется пойти, что иногда можно объединить domain и часть infrastructure и получить всем известный шаблон Active Record или вообще выбросить эти слои и получить шаблон transaction script, когда для решения просто не требуется что-то более сложное. Придет понимание, как можно начать с transaction script и в итоге постепенно катиться в сторону domain layer, через active record или не через active record если это когда-нибудь понадобится и тому подобное. Cтанет понятно, зачем, как и когда использовать патерны о которых написал Мартин Фаулер в своей книге Patterns of Enterprise Application Architecture.

Полученные знания можно применить к любому языку. В том числе и PHP. Будет хорошо, если уровень этого сообщества хоть чуть-чуть будет подтягиваться к уровню Java, вместо того чтобы бомбить пятиуровневые ифы создавая такую цикломатическую сложность, что все метрики кода горят ярче красного.
Ответ написан
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Все зависит от объема проекта. Чем больше и сложнее проект тем больше проектирования. UML прекрасен тем что из него отлично можно сразу генерировать код. Из минусов - не всегда это работает именно так как тебе требуется в проекте. Ну и вообще, я бы предпочел в основном проектировать интерфейсы компонент по тому как внутреннее устройство это уже второй шаг и не влияет на общую картину мира
Ответ написан
Adamos
@Adamos
Делите ТЗ на модули, определяете их внешние интерфейсы (то, что одни модули могут запрашивать у других), стараетесь их минимизировать.
Например, модуль авторизации и аутентификации - это много всего внутри, но снаружи - только общие данные юзера (для вывода) и возможность узнать, авторизован он или нет. Если реализованы права пользователей - то прочим модулям совершенно не нужно знать, как именно (например, принадлежит ли пользователь к какой-то группе). Им нужно узнать, есть ли у него конкретный уровень доступа к конкретному модулю или нет.
Когда определились с модулями - делаете внутри каждого из них аналогичное разбиение на классы: сначала интерфейс, потом потроха.
И только перейдя к реализации каждого класса, можете обернуться на свою процедурщину и посмотреть - есть ли код, который можно оттуда использовать как сырье для методов класса.
Ответ написан
@McBernar
Вместо бумажки — miro. Но суть та же — описать объекты, методы и компоненты, в которых эти объекты собраны. Рядом тут же методы api и структура БД. Но это такоэ. Тоже с удовольствием почитал бы про правильный процесс и софт для проектирования.
Ответ написан
@red-barbarian
Чаще всего, в той сфере где вы работаете уже есть уже принятые архитектурные решения. Бест практики. Придерживаться их - избавиться от многих проблем в будущем.
1. обще принятое - значит не будет сюрпризов для программистов которые сопровождают код
2. не нужно тратить время для изобретения велосипеда.
3. название переменных, пакетов и функций говорят о предназначении в контексте архитектуре.
4. помощь сообщества.
Теперь если программист решил придерживаться общепринятого (хорошего) решения, у него не будет вопросов как организовать ключевые классы. остаются 20% классов для особых случаев (упростить, разбить большие классы и проч) Желательно эти случае решать также "общепринято". Попробовать шаблоны, если они подходят. Типовые решения и типовые названия.
Если нужна для проектирования даже бумажка - это значит есть сложность. Это уже плохо. Эта сложность должна быть очень обоснована. Постараться сделать все максимально просто - это искусство и в этом творчество.)
Ответ написан
Ваш ответ на вопрос

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

Войти через центр авторизации
Похожие вопросы
07 авг. 2020, в 19:51
2000 руб./за проект
07 авг. 2020, в 19:24
4000 руб./за проект