> Приведите пример инкапсуляции (Go)

Короткий ответ

Инкапсуляция в Go - это сокрытие внутреннего состояния и деталей реализации объекта через контроль доступа к полям и методам. На уровне пакета это достигается соглашением о именовании: экспортируемые идентификаторы начинаются с заглавной буквы, неэкспортируемые - со строчной. На уровне типа - через unexported поля и методы, доступ к которым возможен только внутри пакета. Классический пример: структура Account с приватным полем balance и публичными методами Deposit и Balance.

Подробное объяснение

В Go нет ключевых слов private или public, как в Java или C++. Вместо этого используется правило: идентификатор, начинающийся с заглавной буквы, экспортируется из пакета, со строчной - остается внутренним. Это работает на уровне пакета, а не класса. Инкапсуляция на уровне типа достигается тем, что поля структуры объявляются с маленькой буквы, а доступ к ним - через методы.

Основные аспекты инкапсуляции в Go:

• Скрытие состояния: unexported поля не доступны извне пакета, что предотвращает некорректное изменение состояния.
• Контроль инвариантов: методы могут проверять входные данные перед изменением состояния (например, не допускать отрицательный баланс).
• Свобода изменения реализации: внутренние поля можно менять без влияния на внешний API.
• Интерфейсы как граница: инкапсуляция часто сочетается с интерфейсами - внешний код работает с абстракцией, а не с конкретным типом.

Важно: инкапсуляция в Go работает на уровне пакета, а не типа. Если два типа находятся в одном пакете, они имеют доступ к unexported полям друг друга. Это осознанный trade-off: пакет - единица инкапсуляции.

На практике

На практике инкапсуляция применяется для:

• Защиты инвариантов: например, структура BankAccount не позволяет уйти в минус.
• Скрытия сложности: внутренние поля могут быть сложными (слайсы, мапы, каналы), но наружу выставляются простые методы.
• Изменения реализации без ломки API: можно заменить внутреннее хранилище с мапы на БД, не меняя сигнатуры методов.
• Предотвращения случайных ошибок: внешний код не может случайно изменить поле, которое должно быть read-only.

Типичный паттерн - конструктор New..., который возвращает указатель на структуру с unexported полями. Это гарантирует, что объект создается только через валидацию в конструкторе.

Пример кода

GO
package account

import "errors"

// Account - инкапсулированный тип.
type Account struct {
    owner   string
    balance int
}

// NewAccount - конструктор, который проверяет входные данные.
func NewAccount(owner string, initialBalance int) (*Account, error) {
    if owner == "" {
        return nil, errors.New("owner cannot be empty")
    }
    if initialBalance < 0 {
        return nil, errors.New("initial balance cannot be negative")
    }
    return &Account{owner: owner, balance: initialBalance}, nil
}

// Deposit - публичный метод, контролирующий изменение состояния.
func (a *Account) Deposit(amount int) error {
    if amount <= 0 {
        return errors.New("deposit amount must be positive")
    }
    a.balance += amount
    return nil
}

// Balance - публичный метод для чтения состояния.
func (a *Account) Balance() int {
    return a.balance
}

Внешний код не может напрямую обратиться к a.balance или a.owner - только через методы. Это и есть инкапсуляция.

Как отвечать на собеседовании

Начните с определения: инкапсуляция - это сокрытие внутреннего состояния и деталей реализации. Затем объясните механизм в Go: экспорт через заглавную букву, unexported поля, конструкторы. Приведите конкретный пример с Account. Подчеркните, что единица инкапсуляции - пакет, а не тип. Упомяните trade-off: внутри пакета все типы видят unexported поля друг друга. Если спросят про интерфейсы - скажите, что они дополняют инкапсуляцию, скрывая конкретный тип за абстракцией.

Что проверяет интервьюер

Интервьюер проверяет:

• Понимаете ли вы, что в Go нет модификаторов доступа, а есть соглашение об именовании.
• Умеете ли вы проектировать API с защитой инвариантов.
• Понимаете ли вы разницу между инкапсуляцией на уровне пакета и на уровне типа.
• Можете ли вы объяснить, зачем нужны конструкторы и почему не стоит экспортировать поля.
• Осознаете ли вы ограничения: внутри пакета инкапсуляция не работает между типами.

Типичные ошибки

• Утверждение, что в Go есть private и public - их нет.
• Попытка инкапсулировать на уровне типа, а не пакета - это не работает.
• Экспорт полей структуры без необходимости - ломает инкапсуляцию.
• Отсутствие конструктора - тогда внешний код может создать структуру с некорректным состоянием.
• Игнорирование того, что методы с pointer receiver могут изменять состояние, а с value receiver - нет; это тоже часть инкапсуляции.