Дневник изучения Go: запись 1

[darkit]

Все ваши доменные структуры открыты и публичны

 type Expense struct {
  Date time.Date
  Sum float32
  Comment string
}

те делай кто хочешь что хочешь.
Хочешь создавай структуру с отрицательной суммой и датой в будущем.

Стандартная беда Го, что хотим то и пихаем в лист. Никакой безопастности.

type Diary struct {
  Entries *list.List
}

Те если не смогли закомитить транзакцию, то смерть всему приложению???

func (f FileSystemDiarySaveLoad) Save(d *expenses.Diary) {
    ...
    if err != nil {
        panic(err)
    }

В который раз не понимаю зачем на Го пытаться такое писать, потому что выходит или детская поделка или надо так обмазаться кодом, чтобы были и нормальные абстракции и они никуда не текли и ошибки все обрабатывались нормально, что в результате потратите времени когда другие уже закончат три таких проекта.

[Amega]

Спасибо, ваши комментарии вполне справедливы :) Я лишь напомню, что только начинаю изучать Го и некоторые моменты, специфичные для Го, еще очевидно не знаю на все 100%. Но все же отвечу по порядку предъявленных обвинений :)

1) Тут вы безусловно правы. Но это же пока еще только «болванка» для дальнейшей логики. Соотв-но все детали еще конечно не учтены. Если говорить конкретно об этих моделях (Expense и Diary), валидация и прочие вещи еще впереди.
2) Про работу со списком я вроде бы же написал, что этот список будет сокрыт внутри Diary, и вся работа с ним будет производиться исключительно самим Diary, включая и проверку, что туда вообще может попасть. Аналогично про «стандартную беду» Го тоже не соглашусь. Этот пакет предоставляет общее решение для списков, а уж конкретное применение, включая ту же валидацию и прочие вещи, решает уже непосредственно использующая сторона.
3) По этому поводу я уже частично успел оправдаться, говоря о не 100% знании всех аспектов Го :) В данном случае я руководствовался соображениями из других языков, где применяются конструкции вида throw exception; А сам exception, если он предусмотрен заранее, отлавливается выше. Соотв-но по своему незнанию воспринял panic как механизм, аналогичный throw :)

Про «обмазаться кодом» и другие аргументы наподобие «другие уже закончат три таких проекта», то продумывать ли сразу архитектуру приложения или просто наговнячить по-быстрому ради MVP, решает, конечно, каждый сам. И тут уже совершенно не имеет значения, о каком ЯП речь: Го или не Го. Я лишь уточню, что в этом мини-проекте ставлю своей целью в том числе и лишний раз отработать применение архитектурных принципов даже на таком маленьком приложении. Кто знает, может захочу из него потом потом сделать полноценное приложение для ведения финансового учета :) Ну и лишний раз проверить, насколько закладываемая изначально архитектура позволит дальше расширять проект без особой боли.