@dodrator

В каких случаях использовать импортируемые поля в структуре go?

Я слышал, что желательно делать поля неимпортируемыми и использовать геттеры и сеттеры, dependency injection чтобы передавать данные в другие пакеты. Зачем тогда нужны импортируемые поля и какие данные можно делать импортируемыми?
  • Вопрос задан
  • 114 просмотров
Решения вопроса 2
yellow79
@yellow79
Senior Software Engineer
Что бы передавать данные в другие пакеты, которые ничего не знают о ваших геттерах/сеттерах =)
Например encoding/json
Ответ написан
Комментировать
@calculator212
Я слышал, что желательно делать поля неимпортируемыми и использовать геттеры и сеттеры
А где слышали?Вообще это не всегда верно, например даже стандартная библиотека для работы с csv там можно настраивать поля напрямую. В целом если у вас поля с простыми типами данных то в целом это не имеет особого смысла. Это имеет смысл если нужно работать с интерфейса или спрятать за ними часть сложной логики. Насколько я знаю эти идеи тащат люди из других языков, но паттерны которые распространены в Java или C# не всегда подходят для го поэтому не стоит все буквально воспринимать.
На редите есть обсуждение этого вопроса тут.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
DollyPapper
@DollyPapper
Смысл делать поля экспортируемыми есть в очень редких случаях. Один из таких случаев например маршалинг (json/yaml/etc), без экспортируемых полей библиотека просто не сможет засеттить значение в поле. Другие дело обстоит с сущностями (обьектами/структурами вашей предметной области). В случае сущности эта самая сущность должна скрывать свое внутренее состояние и не позволять изменять его извне. Приведу банальный пример:
type User struct {
    Name string
    Age    int
}

И сеттеры геттеры к ней.

Далее допустим есть бизнес правило, что у вас можно регистрировать пользователей строго старше 18 лет. Как вы будете контролировать, что нельзя назначить возраст < 18 лет? Да никак, с экспортируемыми полями это невозможно. Почитать на эту тему можно погуглив про инкапсуляцию и information hiding. В данном конкретном случае геттеры и сеттеры наверное будут более подходящими. В сеттерах можно прописать условие, что возраст должен быть строго больше 18 лет. Однако может быть и такой случай, что сущность не должна вообще более изменяться после создания. Для этого в ООП языках, чтобы задать первоначальные значения существуют конструкторы. В го нет конструкторов, т.к. нет понятия класса, но нам ни что не мешает создать обычную функцию порождающую обьект юзера, и засеттить значения возраста и имени в этой фкнции.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы