Но это стало уже не очень удобным, потому что запросов много, и все их нада выносить в интерфейс.А точно это нужно? Просто если это интерфейс на 20+ методов, то в этом нет смысла, интерфейс нужен для кода, который может быть обобщенным, просто так выносить метод в интерфейс не имеет смысла.
Сейчас дошло до того, что у меня отдельный интерфейс с базой, прокинут в каждый сервис, и для каждого сервиса с есть метод, вынесенный в интерфейс modelВ общем не используйте интерфейсы ради интерфейсов и не получите лишних проблем.
Начал с "Языка программирования Go" Кернигана. Хороший ли это выбор?Да. Только нужно делать упражнения, много полезного есть
паттерн Repository/Unit Of Work.Честно говоря это не очень популярно из-за того, что изолировать при помощи интерфейса не всегда нужно, часто структуры будет достаточно, в которой есть подключение к бд и поле для данных. Есть такой пример. Если у вас планируется несколько источников данных, то возможно вам будет удобнее делать на интерфейсах, но by design интерфейс обычно содержит 1-2 метода, а городить на каждую структуру интерфейс с 5-7 методами немного странное решение для го(с моей точки зрения), чтобы лучше понять го можно прочитать книгу кернигана и книгу 100 go mistakes(примерно так называется), чтобы получше понять суть языка.
просто нет достойных ORMок для GolangБолее приемлимым вариантов считается использование sql билдеров или генерация запросов, честно говоря к этому спорное отношение и где-то вполне себе используют орм.
может правильнее было бы сделать абстр фабрикуЭто и так не самый частый паттерн для применения, а в го тем более. Если хотите через интерфейсы делать, то фабрики хватит. Вообще хз зачем тут так извращаться, по факту в го проще разделить реализацию по пакетам и создавать нужный объект через NewProvider и затем уже делать с конкретной структурой всё что нужно.
У разных банков, будут разные параметры метода Run, получается, я не могу описать структуры интерфейсомНапишите что вы хотите сделать, по ощущениям вы сову на глобус натягиваете.
Есть структура с методом, который принимает на вход массив платежей и некий ключ, который определяет какой банк использовать.Если это то ссылки то фабрики тут хватит, вообще если вы не понимаете зачем вам нужны паттерны, то лучше не использовать их
stCh := make(chan string)
go staffs(stCh)
shop_id := <-stCh
v.Staffs = append(v.Staffs, Staff{
Id: <-stCh,
Name: <-stCh,
Description: <-stCh,
Price: <-stCh,
})
m.Offerz = append(m.Offerz, Offers{v.Staffs})
В целом довольно странно выглядит, так лучше не делать. Пробовал fyne, но он какой-то ущербный, вес огромный после компиляцииЧестно говоря какая-то надуманная проблема, даже если вес 100-200 мб, по современным реалиям это по сути ничто.
Помогите разобраться и написать unit-тест для метода WorkerА что именно, вы хотите протестировать, ну или какая цель у этих тестов? Писать тесты ради тестов обыно плохая идея, т.к. мало желания написать тест, нужно понимать зачем его писать. Для го есть хорошая книга тут, думаю для вашего случая достаточно.
if err != nil {
log.Println("Error sending request to API endpoint.", err)
}
Handler-ы находятся в другом пакете.Тестировать можно в том же пакете, но в целом это не важно, если только вы не делаете их приватными.
И вот вопросом в том, требуется ли мне дополнительная функция, которая бы возвращала *gin.Engine, чтобы я мог в тестововм файле запускать спокойно сервер
func testHTTPResponse(t *testing.T, r *gin.Engine, req *http.Request, f func(w *httptest.ResponseRecorder) bool) {
w := httptest.NewRecorder()
r.ServeHTTP(w, req)
if !f(w) {
t.Fail()
}
}
func TestApiHandler(t *testing.T) {
var a apiService
router := gin.Default()
router.GET("/api/login",a.SignIn)
req, err := http.NewRequest("GET", "/test", nil)
if err != nil {
t.Fatal(err)
}
testHTTPResponse(t, router, req, func(w *httptest.ResponseRecorder) bool {
statusOK := w.Code == http.StatusOK
p, err := ioutil.ReadAll(w.Body)
pageOK := err == nil && strings.Index(string(p), "<title>Register</title>") > 0
return statusOK && pageOK
})
}
package main
import (
"fmt"
"math/rand"
"time"
)
type WordsStruct struct {
Id int
Fword string
Sword string
Freq int
}
func Next(st []WordsStruct) WordsStruct {
rand.Seed(time.Now().Unix())
shw := st[rand.Intn(len(st))]
return shw
}
func main(){
st := []WordsStruct{
{Id: 1, Fword: "test", Sword:"est" , Freq:5 },
{Id: 2, Fword: "rest", Sword:"ww" , Freq:75 },
}
fmt.Println(Next(st))
}