Template Method в Go без наследования

Привет, Хабр!

В статье рассмотрим, как реализовать Template Method-паттерн в Go без наследования, зачем он вообще нужен.

Что делает Template Method и зачем он в бизнес-логике

Классическая формулировка: «Определяет скелет алгоритма в базовом классе, перекладывая реализацию отдельных шагов на наследников».

В CRUD-жизни разработчика это:

• Жёсткий инвариант — шаги алгоритма должны идти именно в таком порядке: например, валидировать > рассчитать > сгенерировать PDF.

• Гибкие детали — как конкретно валидировать или считать, зависит от домена: энергосбыт, телеком, маркетплейс.

В ООП-языках мы бы сделали abstract class InvoiceProcessor и наследников. Go мнит наследование злом и зовёт к композиции. И это плюс: мы получаем не «одну базу, много детей», а модульные кирпичи, которые можно свободно комбинировать между сервисами.

Переписываем OOP-паттерн через composition

Подход № 1: встроенные (embedded) типы

type InvoiceTemplate struct{}  // Skeleton — не экспортируем, чтобы не вызвать напрямую извне. func (tpl InvoiceTemplate) run(i Invoice) error { if err := i.Validate(); err != nil { return fmt.Errorf("validation: %w", err) } if err := i.Calculate(); err != nil { return fmt.Errorf("calculation: %w", err) } return i.Generate() }

Клиентский процессор встраивает InvoiceTemplate и реализует переменные шаги через интерфейс:

type Invoice interface { Validate() error Calculate() error Generate() error }  type PowerInvoice struct { InvoiceTemplate           // embedded kWh   float64 total money.Amount }  func (p *PowerInvoice) Validate() error  { /* … */ } func (p *PowerInvoice) Calculate() error { /* … */ } func (p *PowerInvoice) Generate() error  { /* … */ }

Композицию видно невооружённым глазом. Однако, команды с линейкой кода на проде лихо копипастят InvoiceTemplate, забывают вызывать run.

Подход № 2: делегаты-функции

Go 1.22 всё ещё без дженериков-типа T any, F func(T) error, но банальные first-class-функции работают:

type Step func() error  type Pipeline struct { Validate, Calculate, Generate Step }  func (p Pipeline) Run() error { for _, step := range []Step{p.Validate, p.Calculate, p.Generate} { if err := step(); err != nil { return err } } return nil }

Такой Pipeline можно билдить на лету:

power := Pipeline{ Validate:  validatePower, Calculate: calcPower, Generate:  genPowerPDF, } if err := power.Run(); err != nil { log.Fatal(err) }

Flexibility level 9000, но появляется риск скрепить шаги в неправильный порядок. Лечится генератором или билд-функцией.

Интерфейсы как хуки для поведения

В Go интерфейс — проволока-крючок для DI. Задаём контракт «что нужно сделать», не размазывая «как именно».

type Validator interface    { Validate() error } type Calculator interface   { Calculate() error } type Generator interface    { Generate() error }  type InvoiceSteps interface { Validator Calculator Generator }

Пример внедрения:

type Processor struct { InvoiceSteps logger *zap.Logger env    config.Env }  func (p Processor) Run(ctx context.Context) error { // 1. логи, метрика, trace — общий инвариант p.logger.Info("invoice starting") if err := p.Validate(); err != nil { return err } // 2. расчёт можно отменить контекстом if err := ctx.Err(); err != nil { return err } if err := p.Calculate(); err != nil { return err } return p.Generate() }

Хуки здесь — интерфейсы. Хотите A/B-эксперимент новой формулы тарифа? Просто подмените Calculator в рантайме, не трогая остальной код.

Шаблон «валидация > расчёт > генерация»

Приведу кейс системы биллинга электроэнергии.

MeterReading — показания счётчика. Нужно: проверить данные, рассчитать итоговую сумму, сгенерировать счёт-фактуру (PDF + запись в БД).

package billing  // шаги алгоритма  type readingValidator interface { Validate(reading MeterReading) error }  type tariffCalculator interface { Calculate(reading MeterReading) (money.Amount, error) }  type billGenerator interface { Generate(reading MeterReading, sum money.Amount) (InvoiceID, error) }  // конкретные имплементации  type defaultValidator struct { maxDelta float64 }  func (v defaultValidator) Validate(r MeterReading) error { if r.Value < 0 { return errors.New("negative reading") } if delta := r.Value - r.Prev; delta > v.maxDelta { return fmt.Errorf("suspicious leap: %v kWh", delta) } return nil }  type peakHourCalculator struct { rates tariff.Table }  func (c peakHourCalculator) Calculate(r MeterReading) (money.Amount, error) { var total money.Amount for _, slice := range c.rates.Applicable(r) { total = total.Add(slice.PriceFor(r)) } return total, nil }  type pdfGenerator struct { storage storage.Blob tmpl    render.Template }  func (g pdfGenerator) Generate(r MeterReading, sum money.Amount) (InvoiceID, error) { doc, err := g.tmpl.Render(r, sum) if err != nil { return "", err } return g.storage.Save(doc) }  // сам Template Method  type InvoicePipeline struct { reader      readingValidator calculator  tariffCalculator generator   billGenerator log         *slog.Logger }  func (p InvoicePipeline) Run(r MeterReading) (InvoiceID, error) { p.log.Debug("validate") if err := p.reader.Validate(r); err != nil { return "", fmt.Errorf("validation: %w", err) } p.log.Debug("calculate") sum, err := p.calculator.Calculate(r) if err != nil { return "", fmt.Errorf("calculation: %w", err) } p.log.Debug("generate") return p.generator.Generate(r, sum) }

Логи — structured, чтоб потом кормить в Loki. Конвертации валюты отдали отдельному сервису, иначе курс НБРБ ломал кеш.

Запускаем:

func NewPipeline(cfg config.Billing, s storage.Blob, log *slog.Logger) InvoicePipeline { return InvoicePipeline{ reader:     defaultValidator{maxDelta: cfg.MaxDelta}, calculator: peakHourCalculator{rates: cfg.Tariffs}, generator:  pdfGenerator{storage: s, tmpl: render.InvoiceTmpl}, log:        log, } }

В main.go:

pipe := NewPipeline(cfg, blob, log) id, err := pipe.Run(reading) if err != nil { /* обработка */ }

Когда лучше Strategy или Chain of Responsibility

Когда бизнес-процесс состоит из фиксированной последовательности шагов — скажем, «валидируем > считаем > генерируем отчёт» — и эта линейка меняться не должна, удобнее всего брать Template Method: он задаёт скелет, а детали шагов оставляет на усмотрение внедряемых компонентов. В таких сценариях вы получаете прозрачный инвариант.

Strategy пригождается, когда сама формула алгоритма может радикально меняться от релиза к релизу: мы не просто меняем отдельный шаг, а подменяем всю вычислительную логику целиком. Здесь нужно отдавать разные реализации на ходу, не трогая остальную систему; шаблон даёт именно это, делегируя весь расчёт отдельной стратегии.

Chain of Responsibility вытаскивайте, когда шагов изначально неизвестно или их нужно включать/отключать динамически: каждый обработчик решает, брать ли запрос себе или передавать дальше. Логгеры, middleware, retry-политики, анти-фрод фильтры — классические примеры. Он не фиксирует порядок железобетонно, как Template, но и не требует менять весь алгоритм, как Strategy: вы просто наращиваете цепочку, не лезя в исходники существующих звеньев.

Вывод

Template Method в Go — жив, здоров и прекрасно обходится без наследования. Нужно лишь:

• Держать скелет алгоритма рядом, чтобы не плодить хаос.

• Использовать композицию вместо иерархий: embedded-типы или делегаты-функции.

• Выставлять интерфейсы-хуки минимального размера.

• Писать тесты на каждый шаг и end-to-end.

Если вам по душе идея Template Method без наследования — приходите на открытый урок «Создание микросервиса», который состоится 16 июня.

Следите за расписанием новых открытых уроков по Go и другим темам здесь.