Думаю Go таки ООП-шный язык. Аргументы: - Наследование Есть инструмент interface. Не забываем, что главное в наследовании отношение 'is'. "Наследование реализует отношение 'is' ". Можно же с другой стороны: если есть отношение 'is' то это наследование. Допустим структура А реализует интерфейс I. Это же означает что A is I. Иначе как бы мы, например, использовали параметр типа I и передавали в него A ? Разве это не один из принципов SOLID ? - Полиморфизм Реализуем интерфейс I у двух типов A и B. И получаем чистый динамический полиморфизм. Создаем слайс типа I, складываем в него A и B. запускаем на каждом елементе слайса переопределенную функцию. Поведение будет отличаться на разных типах (A или B). - Инкапсуляция Здесь вообще полный порядок.
Все принципы ООП реализованы. Как же Go не ООП-шный ?
А конкретная реализация ООП да, непривычная. Писать методы вне пользовательского типа неожиданно. Но от этого они не перестают быть обычными методами с полным и управляемым разделением на приватные и публичные. И не становятся ничем другим, кроме как методами по сути.
Алан Кэй считает реализацию ООП в С++ не такой, как он ее себе создал. Это же не говорит о том, что С++ не ООП-шный язык.
Для пустой структуры (type singleton struct{}) всегда создается один объект, или точнее не создается новый. Вообще без использования GetInstance()
s2 := *s1 адрес у обоих объектов один и тот же. Как только появляется поле - ситуация меняется. Даже если это поле вообще не используется. После тестирования обоих вариантов для структуры с полем определенной в отдельном пакете копирование продолжает создавать новый объект. Прямое создание с singleton{} конечно не видится. А просто переменную var _id int можно менять и без ресивера. Обычной func SetId(id int) {_id = id }
Кратко конкретно по этой реализации. Обратите внимание на once.Do() Но в статье речь не о потокобезопасности, а о том, что удачно сформулировал MaxPro33 "в Go не реализован более строгий контроль над созданием экземпляров типа"
Думаю Go таки ООП-шный язык. Аргументы:
- Наследование
Есть инструмент interface. Не забываем, что главное в наследовании отношение 'is'.
"Наследование реализует отношение 'is' ". Можно же с другой стороны: если есть отношение 'is' то это наследование.
Допустим структура А реализует интерфейс I. Это же означает что A is I. Иначе как бы мы, например, использовали параметр типа I и передавали в него A ? Разве это не один из принципов SOLID ?
- Полиморфизм
Реализуем интерфейс I у двух типов A и B. И получаем чистый динамический полиморфизм. Создаем слайс типа I, складываем в него A и B. запускаем на каждом елементе слайса переопределенную функцию. Поведение будет отличаться на разных типах (A или B).
- Инкапсуляция
Здесь вообще полный порядок.
Все принципы ООП реализованы. Как же Go не ООП-шный ?
А конкретная реализация ООП да, непривычная. Писать методы вне пользовательского типа неожиданно. Но от этого они не перестают быть обычными методами с полным и управляемым разделением на приватные и публичные. И не становятся ничем другим, кроме как методами по сути.
Алан Кэй считает реализацию ООП в С++ не такой, как он ее себе создал. Это же не говорит о том, что С++ не ООП-шный язык.
.
Для пустой структуры (
type singleton struct{}) всегда создается один объект, или точнее не создается новый. Вообще без использованияGetInstance()s2 := *s1
адрес у обоих объектов один и тот же.
Как только появляется поле - ситуация меняется. Даже если это поле вообще не используется.
После тестирования обоих вариантов для структуры с полем определенной в отдельном пакете копирование продолжает создавать новый объект.
Прямое создание с singleton{} конечно не видится.
А просто переменную
var _id int можно менять и без ресивера. Обычной func SetId(id int) {_id = id }Давайте использовать термин не "класс" или "структура", а просто "пользовательский тип данных".
Думаете что если использовать термин "структуру", то что-то меняется?
Написать Singleton на С++ для структуры? )
Это я к тому, что не в словах дело.
Кратко конкретно по этой реализации. Обратите внимание на
once.Do()MaxPro33 "в Go не реализован более строгий контроль над созданием экземпляров типа"Но в статье речь не о потокобезопасности, а о том, что удачно сформулировал
Именно об этом и написано в статье. О неправильности подхода "используйте GetInstance()". О контроле над созданием объектов.