Комментарии 11
Когда применять?
Когда пишем не на Go. А на Go так писать не надо, плз.
По сути же это просто функция, которая возвращает разные реализации интерфейса на основе входных параметров. Такого же полно в библиотеках на Go. Что этом плохого? В том, что это можно назвать "шаблоном"?
При этом у автора:
Так как в Golang отсутствуют возможности ООП, такие как классы и наследование
Для создания нового объекта вашего продукта, достаточно создать новый подкласс
Обычно в ООП когда говорят «подкласс», подразумевают наследование. При этом автор вот эту вот вторую часть про расширение скромно опустил как очевидную (и как явно написано, реализовал-то он другую версию шаблона, а не Factory Method), и вот этого противоречия в своем тексте видимо не наблюдает.
В том, что написали Вы — ничего плохого нет. В том, что написано в статье — плохо примерно всё. Что конкретно плохо — по большей части Вы же сами и описали комментарием ниже.
Интерфейс называется iTransport - так не принято, скорее Transport или Transportable.
У геттеров предпочтительнее не использовать префикс get: name() вместо getName()
Пример, конечно, синтетический, но непонятно, зачем интерфейс с неэкспортируемыми методами, который не обладает логикой кроме как установки полей структуры.
Эмбеддинг используется, чтобы эмулировать наследование - это не совсем идиоматично. Лучше стараться избегать такого и использовать другие решения.
Функция создания структуры возвращает интерфейс, хотя идиоматичнее возвратить конкретный тип: в Go т.н. structural typing поэтому паттерны из Java/PHP не так работают: предпочтительнее возвращать конкретные типы, а определять и использовать интерфейсы уже на уровне консьюмера/клиента, тогда структура автоматически приведется к интерфейсу без строгой номинальной привязки. Т.е. некий код говорит, что он хочет принимать в качестве аргумента нечто, что ведет себя как утка, и приведение конкретного типа к интерфейсу происходит в этот момент. Неидиоматично объявлять, что некая структура изначально удовлетворяет какой-то интерфейс (что это её якобы неотъемлемое свойство).
Factory Method Pattern