Комментарии 2
Все ваши доменные структуры открыты и публичны
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)
}
В который раз не понимаю зачем на Го пытаться такое писать, потому что выходит или детская поделка или надо так обмазаться кодом, чтобы были и нормальные абстракции и они никуда не текли и ошибки все обрабатывались нормально, что в результате потратите времени когда другие уже закончат три таких проекта.
-1
Спасибо, ваши комментарии вполне справедливы :) Я лишь напомню, что только начинаю изучать Го и некоторые моменты, специфичные для Го, еще очевидно не знаю на все 100%. Но все же отвечу по порядку предъявленных обвинений :)
1) Тут вы безусловно правы. Но это же пока еще только «болванка» для дальнейшей логики. Соотв-но все детали еще конечно не учтены. Если говорить конкретно об этих моделях (Expense и Diary), валидация и прочие вещи еще впереди.
2) Про работу со списком я вроде бы же написал, что этот список будет сокрыт внутри Diary, и вся работа с ним будет производиться исключительно самим Diary, включая и проверку, что туда вообще может попасть. Аналогично про «стандартную беду» Го тоже не соглашусь. Этот пакет предоставляет общее решение для списков, а уж конкретное применение, включая ту же валидацию и прочие вещи, решает уже непосредственно использующая сторона.
3) По этому поводу я уже частично успел оправдаться, говоря о не 100% знании всех аспектов Го :) В данном случае я руководствовался соображениями из других языков, где применяются конструкции вида throw exception; А сам exception, если он предусмотрен заранее, отлавливается выше. Соотв-но по своему незнанию воспринял panic как механизм, аналогичный throw :)
Про «обмазаться кодом» и другие аргументы наподобие «другие уже закончат три таких проекта», то продумывать ли сразу архитектуру приложения или просто наговнячить по-быстрому ради MVP, решает, конечно, каждый сам. И тут уже совершенно не имеет значения, о каком ЯП речь: Го или не Го. Я лишь уточню, что в этом мини-проекте ставлю своей целью в том числе и лишний раз отработать применение архитектурных принципов даже на таком маленьком приложении. Кто знает, может захочу из него потом потом сделать полноценное приложение для ведения финансового учета :) Ну и лишний раз проверить, насколько закладываемая изначально архитектура позволит дальше расширять проект без особой боли.
1) Тут вы безусловно правы. Но это же пока еще только «болванка» для дальнейшей логики. Соотв-но все детали еще конечно не учтены. Если говорить конкретно об этих моделях (Expense и Diary), валидация и прочие вещи еще впереди.
2) Про работу со списком я вроде бы же написал, что этот список будет сокрыт внутри Diary, и вся работа с ним будет производиться исключительно самим Diary, включая и проверку, что туда вообще может попасть. Аналогично про «стандартную беду» Го тоже не соглашусь. Этот пакет предоставляет общее решение для списков, а уж конкретное применение, включая ту же валидацию и прочие вещи, решает уже непосредственно использующая сторона.
3) По этому поводу я уже частично успел оправдаться, говоря о не 100% знании всех аспектов Го :) В данном случае я руководствовался соображениями из других языков, где применяются конструкции вида throw exception; А сам exception, если он предусмотрен заранее, отлавливается выше. Соотв-но по своему незнанию воспринял panic как механизм, аналогичный throw :)
Про «обмазаться кодом» и другие аргументы наподобие «другие уже закончат три таких проекта», то продумывать ли сразу архитектуру приложения или просто наговнячить по-быстрому ради MVP, решает, конечно, каждый сам. И тут уже совершенно не имеет значения, о каком ЯП речь: Го или не Го. Я лишь уточню, что в этом мини-проекте ставлю своей целью в том числе и лишний раз отработать применение архитектурных принципов даже на таком маленьком приложении. Кто знает, может захочу из него потом потом сделать полноценное приложение для ведения финансового учета :) Ну и лишний раз проверить, насколько закладываемая изначально архитектура позволит дальше расширять проект без особой боли.
+2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дневник изучения Go: запись 1