Go Learning Jam Session

Exploring the basics

• Tests
  • default testing package
  • Go Convey
• Synchronization primitives
  • sync.Mutex/RWMutex
  • sync.WaitGroup
  • sync.Once
• Panics
• Reading/Writing Files
• Shell Commands
• Context
• JSON
  • default json package
  • GJSON
  • SJSON

Design patterns

• Strategy pattern
• Builder + Director pattern

---

Exploring the basics

Tests

default testing package

To run a specific test from a set of tests, you can use the command:

go test -v -run TestMultiple/simple

To run a test in parallel:

 t.Parallel()  

Go Convey

First acquaintance. View full feature tour

---

Synchronization primitives

sync.Mutex/RWMutex

When should it be used? Lock/Unlock when sure that the code of the critical section changes the guarded data, otherwise (does not change) use RWMutex

sync.WaitGroup

Allows to wait for all goroutines to complete at the same time

sync.Once

Allows to run the function only once

---

Panics

An example of how can manage and handle panics using recover()

---

Reading/Writing Files

Introduction to io/ioutil and os packages

---

Shell Commands

The top (table of processes) command shows a real-time view of running processes in macOS/Linux and displays kernel-managed tasks. The command also provides a system information summary that shows resource utilization, including CPU and memory usage

---

Context

Package context defines the Context type, which carries deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes.

---

JSON

default json package

Practice in json.Marshal/Unmarshal

GJSON

Practice in GJSON package

Quick overview of the path syntax :

{
  "name": {"first": "Tom", "last": "Anderson"},
  "age":37,
  "children": ["Sara","Alex","Jack"],
  "fav.movie": "Fear and Loathing in Las Vegas",
  "friends": [
    {"first": "Dale", "last": "Murphy", "age": 44, "nets": ["ig", "fb", "tw"]},
    {"first": "Roger", "last": "Craig", "age": 68, "nets": ["fb", "tw"]},
    {"first": "Jane", "last": "Murphy", "age": 47, "nets": ["ig", "tw"]}
  ]
}

"name.last"          >> "Anderson"
"age"                >> 37
"children"           >> ["Sara","Alex","Jack"]
"children.#"         >> 3
"children.1"         >> "Alex"
"child*.2"           >> "Jack"
"c?ildren.0"         >> "Sara"
"fav\.movie"         >> "Fear and Loathing in Las Vegas"
"friends.#.first"    >> ["Dale","Roger","Jane"]
"friends.1.last"     >> "Craig"

View full feature tour

SJSON

Practice in SJSON package

View full feature tour

---

Design patterns

Strategy pattern

is a behavioralgn pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

Greate explanation from Israel Miles on Medum

---

Builder + Director pattern

is a creational pattern designed to provide a flexible solution to various object creation problems in object-oriented programming. The intent of the Builder design pattern is to separate the construction of a complex object from its representation.

Greate explanation from josué Parra Rosales on Medum

---

Free formulation of SOLID principles

S - Single responsibility principle (SRP) Принцип единственной ответственности.

Если у нас БД, пишем сервис по работе с БД. Для очередей пишем отдельный сервис по работе с очередями.
Потом будет третье звено, которое знает и о БД и об очередях. БД об очередях не знает.
Каждый объект программы должен знать только об одной (своей сфере). Иметь единственную ответственность.
Ответственности прописываем на уровне пакетов (подпакетов) .pkg/database/client-db.go и .pkg/amqp/client.go

O - Open/Close principle (OCP) Принцип открытости/закрытости.

Каждый сервис/структура должна быть открыта для расширения (добавление нового функционала), но никак для изменения.
Для добавления новых функций - открыта. Для редактирования - закрыта.
Один раз что-то создали и в дальнейшем это не менять.
Как пример - создаем общий интерфейс (тем самым закрыли функционал на добавление чего-либо), а в структурах уже
начинаем расширять данный интерфейс.

L - Liskov substitution principle (LSP) Принцип подстановки Барбары Лисков

Функции, которые используют базовый тип должны иметь возможность использовать подтипы базового типа не зная об этом.
Когда интерфейс можем реализовать в каком-то наследнике.

I - Interface segregation principle (ISP) Принцип разделения интерфейсов

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

D - Dependency inversion principle (DIP) Принцип инверсии зависимостей

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.
Сами абстракции не должны зависеть от деталей.
Нужно применять такой принцип, когда мы внутри структуры реализуем функционал, мы не должны реализовывать от какого-то
объекта. Объект нужно привести к интерфейсу.
Как пример - выполнять взаимодействие с БД только через интерфейс. Никогда не нужно выполнять через реализацию.