Comments 6
Похоже на перевод статьи или главы из книги.
Код совпадает с https://github.com/paolochang/go-fundamentals/blob/master/03-Methods-and-Interface/03a-people.go
Но вы можете подумать, а зачем вообще что-то было на мапе сотрудников? Похоже, мы не объявили
employeeполем указателя, но это так.
Как это можно читать? Так предложения не строят в русском языке! Чему могут научить преподаватели OTUS если они по русски не могут изъясняться?
Преподаватели OTUS прекрасно изъясняются по русски и являются экспертами в своей области. Рустем - это преподаватель, владеющий тремя языками, которые использует ежедневно. Русский язык не является основным, так как Рустем родился в англоязычной семье, поэтому отдельные формулировки и лексические обороты иногда выглядят немного странно. Мы стараемся исправлять такие формулировки, в случае их возникновения. Благодарим за то, что указали на данный недочет.
У нас также есть фабричная функция NewSimpleEmployeeData, чтобы убедиться, что мы используем правильно сконструированный экземпляр SimpleEmployeeData не нужно писать фабричную функцию, но это хорошая практика, если вам нужно убедиться, что определенные поля в структуре правильно заполнены, прежде чем они будут использоваться. В этом случае необходимо убедиться, что карта сотрудников не равна нулю.
Тут плохо всё. Во-первых "ведущий эксперт OTUS" не понимает разницы между паттерном Фабрика и конструктором. Конкретный экземпляр конкретного типа возвращает второй, а не первый. Во-вторых в Go фабрики не нужны в принципе т.к. "единственный абстрактный тип" ((с) автор) в Go не используется так, как в Java или C#, откуда к нам фабрики и пришли.
type EmployeeData interface {
AddEmployee(firstName, lastName string, dateHired time.Time) int
GetEmployee(id int) (Employee, bool)
AddManager(firstName, lastName string, dateHired time.Time, reports []int) int
GetManager(id int) (Manager, bool)
}
Гоферы так не пишут. Тут вам не Java, интерфейсы объявляются там, и только там, где используются. Это единственный способ нормально "разобрать" (decoupling) код и ослабить его связанность. Паттерны из Java делают Go-код абстрактным очень условно, по факту, он будет "прибит гвоздями". Ну посмотрите внимательно на этот интерфейс и его методы. Не может быть у вас второй реализации этой ерунды, она всегда будет одна. Уж в Go интерфейс для одной реализации не нужен точно.
Кстати сами методы просто ужасны. Они должны быть просто Add и Get. Empoyee и Manager или должны быть одним типом с полем bool внутри (оно будет определять кто менеджер) или разными типами, но в разных пакетах, тогда у нас будет
Employee.Add(), Employee.Get(), Manager.Add(), Manager.Get()
Так и интерфейс лишь с двумя методами получит смысл.
Остальное и разбирать лень. А денежки лучше в gopl.io вложить, чем в такие курсы.
Типы, методы и интерфейсы