и их поведении/отношениях. Анемичная подразумевает, что бизнес-логика пишется процедурно (в сервисах или даже plain-функциях), а классы - это просто структуры для передачи данных
В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру?
> Соответственно, в го, без дженериков и прочего мета-программирования очень сложно делать всякие хитрые паттерны, основанные на отношениях объектов.
Каккие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы.
> А в php ты изи можешь описать, скажем, десять классов подтипа "заказ" и написать универсальную функцию, которая единообразно обрабатывает любой класс из вышеперечисленных.
Что мешает использовать композицию вместо наследования? Я где-то читал (возможно ошибаюсь) что создатели go и решили не включать в язык наследование потому, что можно использовать композицию
В пхп нет строгой типизации, поэтому и дженерики не нужны.
> В go же аналог класса - это структура. Что мешает засунуть бизнес логику в структуру? Ничего, кроме того, что ты не сможешь нормально написать достаточно универсальный код для обработки _разных_, но схожих структур. Например, у тебя есть список пользователей и список клиентов (наборы полей разные, но в чём-то схожи). Ты вряд ли сможешь обрабатывать их одинаково, без копипаста. С теми же дженериками смог бы. А в php ты можешь перечислить несколько типов через | или вообще обращаться к полям, не зная типа (что есть антипаттерн, но тем не менее). Да, на это есть хаки, но я говорю о принципиальных вещах. > Какие паттерны, например? В php же тоже нет дженериков, но паттерны вполне себе реализуемы. Читай https://habr.com/ru/company/jugru/blog/503868/, раздел про агрегаты. > Что мешает использовать композицию вместо наследования? Ни та, ни другая в одиночку всех проблем не решает.
Обсуждают сегодня