UML-модель Yii2-приложения, реализация интерфейса группой классов. Как? Есть ли под это паттерн?

Question

[Vicom]

Всем привет. Нужен спец по ООП и UML, который работал в своё время с MVC!

Я только учусь (сам, курсы и другие варианты не предлагать), но очень много времени на конкретно проектирование в UML - нет, + маловато опыта в ООП, поэтому прошу совета. Читаю GOF, Зандстру и т.п. Сейчас пишу простой двиг управления каталогом. Типовые CRUD-ы везде где только можно по сути составляют основу проекта. Но я делаю его исходя из задач тренинга, чтобы грамотно заюзать полученный скилл, уделив внимание BP в другом проекте (интернет-магазины и проч.).

Задача 1
Грамотно и к месту использовать возможности интерфейсов. В данном случае я до конца ещё не понял нужно ли мне это или я так же могу воткнуть между Base[классом] и конечным классом - т.н. Real[класс], или лучше для этого использовать интерфейс? тела у класса скорее всего не будет, т.к. RealClass по сути это обобщённый класс, который, однако предназначен для использования уже в зоне домена. Т.е. это базовый класс домена, если мы отодвинемся чуть подальше и посмотрим уже в масштабе метамодели.

Отсюда вопрос - лучше интерфейс или промежуточный класс (..а вдруг потом для всех в домене придётся доп. функции писать или конструктор модифицировать? вот хрен угадаешь. с другой стороны если так рассуждать - можно про любые интерфейсы это утверждать, которые не используются для множественного наследования, или я ошибаюсь?)

Задача 2
Просто написать "[classname] implements [interfacename]" конечно можно в коде в каждом классе. Но есть ли более элегантное решение данной задачи? Идея на самом деле стара как мир: приучая себя к DRY использую повторно типовые CRUD-action-ы в разных контроллерах Yii, но может тут где-то зарыта оптимизаторская собака, которую я, по неопытности ещё не успел откопать?
Субзадача: как лучше отобразить в UML отношение группы элементов к другому (например ту же реализацию интерфейса множеством Action-ов) без необходимости рисовать её от каждого элемента (рука отвалится, если их 100). Посоветуйте визуальный шаблон вроде: группа (объект1 -> Int, объект2 -> Int, ... , ОбъектN -> Int), где Int - интерфейс, "->" - вид связи, а Объект - Action в нашем случае.

Примечание
- Base[classname] - wrappers для обеспечения ровного обновления самого Yii в дальнейшем, не обращайте внимания.
- заранее напомню: для такой простой задачи я пилю UML исключительно в целях тренинга и осваивания
ООП, к тому же этот проект имеет шансы вырасти и масштабироваться, тем паче нужна грамотная архитектура с самого начала.

С благоговением и надеждой прилагаю диаграмму классов, DDL-схему и макет интерфейса, чтобы максимально быстро и без напряга можно было бы дать мегаполезный совет зелёным в ООП чувакам вроде меня.

Заранее спасибо.

Answer 1

[Сергей Протько]

Нужен спец по ООП и UML, который работал в своё время с MVC!

Наблюдаю тут несостыковку. Обычно когда говорят о UML - вот все эти вещи вроде контроллеров и т.д. расписываются на уровне компонентов. В UML обычно описывают только доменную логику, то есть то что важно.

В любом случае в Yii такие подходы работают очень плохо. Там вы не ООП делаете а базу данных проектируете (это чуть разные вещи), и все остальное уже от этого отталкивается.

Если вы хотите по UML фигачить (не понятно зачем правда, но это уже ваше дело), то имеет смысл брать какую ORM заточенную под ОО-first (по сути Doctrine2 из ныне существующих) и там уже развлекаться. Там профит будет.

p.s. забудьте об этой бесполезной для бэкэнда аббревиатуре MVC. Пока вы "проектируете контроллеры" - толку от него нет (ну то есть пока у вас логика работы с данными в контроллере).

Читаю GOF, Зандстру и т.п.

Почитайте Applying UML and Patterns - Craig Larman - замечательная книга. Еще дядю боба можете почитать (про SOLID). Если вас интересуют темы проектирования то это будет полезно. Еще раз уж заговорили о проектировании логики предметной области - Эрик Эванса - Предметно ориентированное проектирование.

Задача 1

1) композиция всегда лучше наследования
2) наследование нужно для того что бы организовать подтипы. Если у вас есть сущности которые по своей природе требуют наследование - то можно. А так - лучше его избегать. ООП как бы не про наследование вообще.
3) интерфейсы нужны для того что бы организовать инверсию зависимости и/или полиморфизм подтипов. У Лармана можете почитать про protected variations для того что бы понять зачем их юзать.

Задача 2

В UML отношения между типами очень легко и просто отображаются:

- Base[classname] - wrappers для обеспечения ровного обновления самого Yii в дальнейшем, не обращайте внимания.

Как это не обращать внимания если вы делаете UML ради UML? Пока я не увидел ничего от ООП на вашей диаграмке. Есть структуры данных с публичными пропертями, есть... контроллеры (внезапно) которые мутируют состояние этих структур.... Это не ООП - это процедурное программирование с классами.

для такой простой задачи я пилю UML исключительно в целях тренинга

Пока это выглядит как впустую потраченное время, поскольку вы выбрали не лучший инструмент (yii) что бы тренироваться проектировать ОО решения.

Я рекомендовал бы вам:

- Разобраться что такое ООП на самом деле (это не про инкапсуляцию. полиморфизм и уже тем более не про наследование ибо все это было еще до ООП и все это кроме наследования является важными принципами структурного программирования). Это про сокрытие состояния и управление зависимостями (связанность, coupling & coheasion у Лармана)
- Взять более подходящие для проектирования ОО решений инструменты (какой-нибудь модный нынче Laravel + Doctrine2)
- если хотите продолжать баловатся с Yii сделайте так, что бы логика предметной области ничегошеньки не знала о Yii, тогда вообще не нужно будет заниматься этими Base* классами. Почитайте про Row Data Gateway (это по сути предшевственник ActiveRecord) а именно как оно использовалось в контексте модели предметной области.

Есть ли под это паттерн?

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

Оригинальная книга по GoF в этом плане так себе, сейчас лучше смотреть в сторону Head First Design Patterns Ну и помимо паттернов нужно разобраться с общими принципами такими как закон деметры, SOLID, GRASP и т.д. Тогда понимание всего будет более системным.

Comments

[Vicom]

Короче я долго писал Вам ответ и благодарность ещё несколько месяцев назад, но так развёрнуто, что до сих пор руки не доходят дописать. Причём самое смешное, что это в связи с тем, что Ваш ответ так хорошо меня мотивировал и ускорил что пришлось забить навремя на UML и продолжить разработку. Теперь вернулся к нему, но уже легче всё видеть и понимать. В общем больше спасибо в любом случае, никто не забыт, ничто не забыто. =)

а UML на самом деле вещь шикарная, но проектировать контроллеры, вероятно, было не лучшей идеей. Там итак уже есть проверенный годами подход и правила их использования. Городить особо смысла нету. Ну если только местами, для себя и только ключевые моменты (как мы знаем часть классов, методов или атрибутов можно опускать в диаграммах, если они не имеют прямого отношения к обсуждаемому контексту, несмотря на то, что вовлечены в процесс выполнения алгоритма так или иначе)

а вот для Workflow очень даже пригодился)
может быть дадите свою рецензию? (задача - есть процесс, который имеет статусы, стадии и визуальное отображение текущей стадии, по сути - расширенная State Machine)



Реализация бизнес-задач через декларативный код, конфигурирующий отнаследованный экземпляр класса VisualProcess (по сути StagedProcess, который можно отобрать в лицо человеку с помощью $instance->render())



PS вполне вероятны частичные расхождения между кодом и диаграммой (т.к. на каждый чих перерисовывать не тащит, на ключевых этапах только перерисовку делаю), но основная суть, надеюсь, понятна

[Vicom]

увидел тут в прошлом ответе..

- если хотите продолжать баловатся с Yii сделайте так, что бы логика предметной области ничегошеньки не знала о Yii, тогда вообще не нужно будет заниматься этими Base* классами. Почитайте про Row Data Gateway (это по сути предшевственник ActiveRecord) а именно как оно использовалось в контексте модели предметной области

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

// launching fill process with empty object record (first step only)
$newCategoryProc = CreateCategoryProcess::get($newCategory->id, CreateCategoryProcess::CREATE_NEW);

// always running process, all conditional code was above
$newCategoryProc->run();

+ результат render() передаю во вьюху

$model = [
            'process'       => $newCategoryProc,
            'processView'   => $newCategoryProc->render()
            ];

return $this->controller->render($this->viewName, ['model' => $model]);

про подход с хранением - пока маппер подошёл, поверх AR, чтобы избавить процесс от обновления инфы о себе непосредственно через AR - делегировал задачу мапперу, как и получение метаданных процесса (id, state, stage etc.) из хранилища