если можно написать такой код без интерфейсов? строк будет даже меньше(если будет куча обьектов).
https://go.dev/play/p/NvDrl8NmrR3 - без интерфейсов
https://go.dev/play/p/Cav0rkO7-Qo - с интерф
Интерфейсы нужны в первую очередь потребителям в конечном счёте методов ваших структур, а не структурам. Это звучит несколько странно, но в го это так. Идея в том чтобы потребитель видел не все методы структуры, а только тот набор что ему нужен - это уменьшит сложность подмены реализации для потребителя. И да, интерфейс можно и лучше даже писать рядом с потребителем, а не реализацией (что прямо противоположно опыту в джава например)
а влияет это как-нибудь на память и время?
вот тебе пример interface Notifier { SendNotify(message string) error } func (m *OrdersManager) createOrder(model Order, notifier Notifier) error { // code notifier.SendNotify(«Order created: » + order.Id) } при этом у тебя может быть много нотификаторов, начиная от мыла, заканчивая смс и тд
Вряд-ли существенно для того чтобы этим не принебрегать. В остальном - профилирование не отсеняли
Привидение к внутреннему типу занимает
Вот в догонку о чем я талдычил : https://youtu.be/eYHCCht8eX4
Не противоречит джаве Везде код пишется там, где используется или максимально близко к этому месту Все практику по отдалению — плохие. Например анемия — вынесение логики изменения стейта сущности снаружи от сущности… отделение сущности от сервисов, работа с ней по слоям: получается забавная ситуация, когда сервисы для юзера и заказа вместе, но сервис заказа далеко от заказа 😂 Например в джаве возьмём какой-нибудь валидатор, интерфейс валидаторов и констрейнты будет рядом с движком , а реализации могут находиться на клиентской стороне
Ну напиши мне на джаве класс без указания наследования и используй интерфейс для его вызова - речь о этом Видосик пояснит лучше чем чат
Речь если об этом, то зачем написали о другом?
на этом примере не понять Нужны для DI в первую очередь. А потом для DIP
Обсуждают сегодня