это из саттера https://it.wikireading.ru/27507

Ну как) Не дают сейчас конечно же, но это так потому что не использую. А чтобы понять надо ли использовать, надо их хоть в какой-то степени знать.
Из паттернов максимум, что понимаю это адаптер и наблюдатель.
А в целом, чтобы просто приобщиться к теме.

А. Еще. Изучаю ооп, чтобы к солид подступиться. Чтобы больше смысла в нем видеть.

Почему все говорят про эти два термина, но не упоминают агрегацию? Существует же 3 разных вида ассоциации.

Это как не упомянать виды полиморфизма

Потому что композиция подразумевает агрегация? Ну т.е. является более строгой ее формой?

Я бы воздержаться говорить что что-то из этого это более строгое что-то другое.
На самом деле вы достаточно правильно заметили что противопоставление агрегации наследованию формально более правильное. Т.к. и наследование и агрегация имеют один(с точки зрения проектирования) срок жизни объектов.

чёта выглядит как буллшит какой-то "в случае наследования классов упрощается также задача модификации существующей реализации" или мне кажется? 🤔

может быть если по дороге не наступил на грабли и не прострелил все конечности. Как это "если аккуратно использовать", но опять же упрощение в плане реюза выглядит не то чтобы критичным.

Ну в целом да, но я думаю так можно свернуть на скользкую дорожку - подбирая паттерн под задачу, нежели думать - как сделать проще и понятнее

“А. Еще. Изучаю ооп, чтобы к солид подступиться. Чтобы больше смысла в нем видеть.”
Я бы с солида начал. Для солида вообще не нужно знать сложные ООП конструкции. Там про другое. Его можно и без классов юзать

Рефералка есть?))

Всем привет. Возможно задам глупый вопрос, так как все еще плаваю в понятиях, но все же.
Делаю на одном проекте API на RPC (если быть точнее JSON RPC), поскольку эстетически больше нравится чем тот же REST и просто интересно "пощупать" что-то новое. Так вот, в этом случае, RPC - методы выступают теми же контроллерами, которые просто вытягивают данные из запроса, частично может валидируют и передают уже на слой бизнес логики ниже, или здесь можно замапить RPC методы буквально напрямую на методы (или юзкейсы) из доменного слоя, убрав таким образом чуть ли не целый слой и возможный бойлерплейт код? Или это по сути значения не имеет или я что то путаю? Заранее спасибо.

Нет

убрать слой конечно можно, но это ничего не решит... код придется переносить либо выше, либо ниже... а зачем? быстрее не будет... а так ты можешь менять например rest на rpc/ajax или rpc/ws... так что я бы оставил слой, тем более если собирать из готового он неизбежно будет

Помогите, плиз - как лучше спроектировать API?
Сейчас такого вида:

/user/sign-up/email/as-team
/user/sign-up/email/as-company
…
/user/sign-up/phone/as-team
/user/sign-up/phone/as-company
…

Нужно добавить возможность дочерних аккаунтов. Соотвественно регистрация таких аккаунтов уже будет возможна только для аутентифицированных пользователей с таким же типом (as-company/as-team/…).

Можно по идее отправлять при регистрации доп поле “parent”. И если оно есть, то менять правила доступа к sign-up. Но по моему это не очень иметь разные правила security для одного урла.
Алтернатива получается плодить по новому урлу для каждой такой регистрации - типа:

/user/sign-up/root/email/as-team
/user/sign-up/root/email/as-company
/user/sign-up/child/email/as-team
/user/sign-up/child/email/as-company
…
/user/sign-up/root/phone/as-team
/user/sign-up/root/phone/as-company
/user/sign-up/child/phone/as-team
/user/sign-up/child/phone/as-company
…

Может есть варианты получше? Как вы видите решение?

Проектировать интерфейс надо из того как им будут пользоваться, ты этой инфы не предоставил.

Условно как клиент выбирает из доступных стратегий и т.д. почему может дёрнуть тот или иной метод. Вдруг удобнее будет просто post signup и в боли все что надо для выбора стратегии

Если клиенты разные - методы под клиентов

А зачем все через url передавать? в самом запросе и дальше уже рулить

as-team/as-company/…
это обязательная инфа для типа юзера. Одни регистрируются как бригада с нужными полями, другие как наниматели бригад и тд
помимо выбора при регистрации типа - можно выбрать как аутенитифицироваться: email/phone/oauth2 services/…

далее отдельно уже внутри своего профиля - можно зарегать дочерние акки.

Типа вот эту часть child/email/as-team - в параметры?
Да - логично. Я просто наверное не очень понимаю что пихать в url, а что в параметры. Какой тут принцип, от чего отталкиваться .