По канонам современных публичных выступлений тут должно быть оправдание, сглаживание углов, но его не будет. Мы пойдем по порядку: абстракция, инкапсуляция, наследование, полиморфизм.

Абстракции?

Abstractio или отвлечение — уход от не существенных свойств объекта ради простоты восприятия и оперирования понятием(объектом).  Даже команды процессора — определенный уровень абстракции нам передаваемым сигналом, не говоря уже об ассемблере. Все программирование(и все языки программирования) частично абстрактно и частично конкретно, вопрос только в уровнях абстракции.

Показывает ли Go тот же уровень абстракции как python, java, php или С++? Объективно нет.  Даже перечисленные языки имеют разные уровни абстракции! Важная особенность Go в том, что часть абстракций Go выносит на уровень пакетов, а часть абстрактных решений принимает за нас. Например, в виде утиной типизации. И это важный момент, который мы рассмотрим позже в части, почему «прекрасно, что в Go нет ООП». А пока мы должны понять, что абстракция — свойство программирования в целом, а не ООП.

Инкапсуляция?

Классическое понимание инкапсуляции в ООП — это реализация принципа абстракции данных. На самом деле, чистой абстракции данных нет даже в C++ и Java. Её иногда называют «неполноценной». Видимо, что бы я смог отнести их к разряду языков с ООП.

В Go ситуация ещё «круче». Инкапсуляция на уровне интерфейсов и пакетов. Что? Опять частично все решили за нас? Именно. Приватные и публичные идентификаторы внутри пакетов. Нет инициализаторов и конструкторов. Методы — как и везде синтаксический сахар над функциями. Интерфейсы? Не те интерфейсы, что в других языках — только контракты на уровне типов.

Таща за большой хвост, невзирая на визги и стоны, всё это можно назвать инкапсуляцией. Добавим оговорки не полноценная и особенная и попадем в канон, но я не собираюсь делать из Go инвалида! Так что без меня.

Наследование?

Его в Go нет. Вкусно и точка!

Полиморфизм?

Интерфейсы. Опять? Дженерики. Дождались и не все хотят юзать. Не поднимая теорию полиморфизма, в конечном итоге все это сводится к возможности функций  принимать разные типы аргументов, а это было в Go всегда.

А теперь о прекрасном!

Я специально не вдавался в подробности, что бы не уходить в научные споры. Я практик и наверное это самое отвлеченное, что я написал. Основной идеологией OOП всегда был перенос проблем процедурного программирования на более высокий уровень абстракции, что бы обеспечить  управление крупными проектами.  Это всегда работало и в моем коде тоже. Но потом я познакомился с GO.

Как мы поняли, что ООП — это всего лишь стиль программирования, который позволяет управлять сложными программами через повышение уровня абстракции. Go тоже позволяет, но кто не согласится, что структуры встроенные в структуры — это ужас? Однако Go решает проблемы написания сложных программ. Именно решает, а иначе бы не появились бы такие программы как Kubernetes или Gitea.

В отличие от языков с ООП, Go переносит решение на более низкий уровень абстракции, но не позволяет опустится так низко, что бы создать проблем:

• Мы выносим общие части на уровень пакетов и Go дает отличные инструменты, которые привычны программистам (Git, SVN, Mercurial и т. д.), что бы работать с ними.

• Ограничение доступности как данных, так и реализации глобально так же вынесено на уровень пакетов.

• Понятий объекта и класса нет, потому что они так же понижены до уровня структуры данных, способа изменения содержимого метода, который низведен до функции с ресивером и контракта в виде интерфейса

Вот и все — те же проблемы с организаций кода понижены в статусе и поэтому в Go нет ООП, он решает те же задачи принципиально другим подходом.

Можем ли мы реализовать те же подходы, что использует ООП — можем. Go язык с высоким уровнем абстракции — имитируйте, что душе угодно. Даже ООП. Но! Помните, что модный и удобный gRPC опустил ваши абстракции до кодогенерации. Спасибо, что прочитал такую абстрактную статью!