иными словами - нужно чтобы функция main из примера продолжала выглядеть так же или лучше, но при этом весь демо-функционал мог работать?

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

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

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

мне надо это прочитать, или я могу дописать - важно, понимать - условия задачи, которые я изложил выше - я понял правильно?

https://github.com/gorgonia/agogo - смотрите, какие классные штуки пилят на Go:)

какое-то машинное обучение? тут как бы не получилось, что такая штука "написанная" на Питоне, используящая tensorflow не оказалось в несколько раз быстрее

https://play.golang.org/p/jWiB3GY4IrI

Этот код хуже расширяется и нарушает Open/Close Чем больше провайдеров у нас будет, тем страшнее будет выглядеть твой свитч, и тем сложнее будет ориентироваться в множестве функций отправки. Об этом кстати Фаулер писал https://refactoring.com/catalog/replaceConditionalWithPolymorphism.html Давай представим что в нашем проекте требуется логика отправки картинок. Можешь пожалуйста добавить её в свой пример для каждого провайдера. Вызов в main должен выглядеть примерно так sender.SendTo(u2,"just telegram", Telegram) // сообщение в телегу sender.SendImage(u2, image{}, Telegram) //картинка в телегу image это просто пустая структура пусть будет

расширяется он прекрасно, это станет очевидно, когда будет создаваться полноценное решение, в котором будет столько boilerplate на тему представления сетей и проч, что скорее всего даже switch не будет... будет что-то иное, м.б. visitor pattern, но пока messengers меньше 10 - так будет ок

просто еще один леер вырастет про сообщение

func telegramImage(u UnifiedContact, img image) { log.Printf("telegram image: %s, %s\n", u.Name, img.size) }

сообщение должно быть единое

type image struct { size string } картинку можно просто вот так сделать

не надо так делать, потому, что потом надо будет расширять протокол, и это должно быть очень просто

я считаю, что достаточно заменить у msg тип string на тип приведенный мною выше

type UnifiedMessage struct { Text string Media []*MediaFiles Entities []*Entities Author *UnifiedContact Receivers []*UnifiedContact } func (s* Sender) SendTo(u UnifiedContact, msg UnifiedMessage, targets... NetworkType) error {

type UnifiedMessage struct { Text string Media []*MediaFiles Entities []*Entities Author *UnifiedContact Receivers []*UnifiedContact } func (s* Sender) SendTo(u UnifiedContact, msg UnifiedMessage, targets... NetworkType) error {

https://play.golang.org/p/owry8QuZQHu

А где отправка картинки? log.Printf("telegram image: %s, %s\n", u.Name, img.size)? Представь что там разные эндпоинты апи, ну даже если у телеги один, то у ватсапа или смс провайдера будет другой

и к обсуждаемому вопросу вообще не имеет отношения

там правда отправка файлов и текстов, но сути это совершенно не меняет

https://play.golang.org/p/owry8QuZQHu

там правда отправка файлов и текстов, но сути это совершенно не меняет

Я бы посмотрел, как изменится код, если кроме sendTo нужна будет ещё одна функция, какая-нибудь типа editMessage

так или иначе, я все же хочу заметить, что задача Ваша решена, без interface, я понимаю, что это больно, но по-моему, уже было бы честно согласиться с этим:)

ну хотя бы потому, что доказывать - обязанность утверждающего, Ваша милость говорить, что потом будут какие-то проблемы, весьма мутно описанные, и в качестве подтверждения просит меня написать что-то:)

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

достаточно отправлять не сообщение сообщение, а сообщение - NewMessage, Delete, Update, ... - опять же призываю глянуть на tdlib

вот же)

это тоже легко -

Ладно, можно тогда вот логику с проверкой возможности доставки от провайдера? https://t.me/golangl/13637 ну вот это И в плейграунде