Полиморфные коллекции

Часть раздела Объектно-ориентированное программирование путешествия по GO на Coddy. Урок 44 из 107.

Одно из самых мощных применений интерфейсов — хранение разных типов в одной коллекции. Срез типа интерфейса может содержать любое значение, удовлетворяющее этому интерфейсу, позволяя объединять связанные, но разные типы.

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

type Shape interface {
    Area() float64
}

type Circle struct{ Radius float64 }
func (c Circle) Area() float64 { return 3.14159 * c.Radius * c.Radius }

type Rectangle struct{ Width, Height float64 }
func (r Rectangle) Area() float64 { return r.Width * r.Height }

func main() {
    shapes := []Shape{
        Circle{Radius: 5},
        Rectangle{Width: 4, Height: 3},
        Circle{Radius: 2},
    }
    
    for _, s := range shapes {
        fmt.Printf("Area: %.2f\n", s.Area())
    }
}

Срез shapes содержит и круги, и прямоугольники. При переборе каждый элемент отвечает на вызов Area() в соответствии со своим фактическим типом. Это применение полиморфизма к коллекциям: один и тот же цикл единообразно обрабатывает все типы фигур.

Полиморфные коллекции необходимы при создании систем, обрабатывающих разные элементы: системы уведомлений, отправляющей электронные письма и SMS-сообщения, игры, обновляющей разные типы врагов, или обработчика документов, работающего с несколькими форматами файлов. Коллекции не важны конкретные типы: важно лишь, чтобы каждый элемент предоставлял необходимое поведение.

Задание

Легко

Давайте создадим систему управления задачами, которая обрабатывает разные типы задач через единый интерфейс. Вы создадите различные типы задач и будете обрабатывать их вместе в полиморфной коллекции.

Вы распределите код по трём файлам:

task.go: Определите интерфейс Task, требующий метод Summary() string. Этот интерфейс станет общим контрактом, которому должны соответствовать все типы задач.
types.go: Создайте три разных типа задач, каждый из которых реализует интерфейс Task:
- BugFix с полями ID (string) и Severity (string). Метод Summary() возвращает Bug #[ID] ([Severity])
- Feature с полями Name (string) и Points (int). Метод Summary() возвращает Feature: [Name] - [Points] pts
- Documentation с полем Topic (string). Метод Summary() возвращает Docs: [Topic]
main.go: Создайте функцию PrintBacklog, которая принимает срез Task и выводит сводку по каждой задаче на отдельной строке. Считайте сведения о задачах из входных данных, создайте по одной задаче каждого типа, соберите их в один срез []Task и передайте его в PrintBacklog.

Будут предоставлены следующие входные данные:

Строка 1: ID ошибки
Строка 2: критичность ошибки
Строка 3: название функциональности
Строка 4: количество баллов функциональности (целое число)
Строка 5: тема документации

Например, если заданы 1042, critical, Themes, 8 и API, результат должен быть таким:

Bug #1042 (critical)
Feature: Themes - 8 pts
Docs: API

Преимущество такого подхода в том, что PrintBacklog не нужна отдельная логика для ошибок, функциональностей или документации. Функция просто перебирает срез и вызывает Summary() для каждого элемента. Каждый тип задачи возвращает собственную уникальную строку в заданном формате, что показывает, как полиморфные коллекции позволяют единообразно обрабатывать разные типы.

Попробуйте сами

package main

import (
	"fmt"
)

// TODO: Создайте функцию PrintBacklog, которая принимает срез Task
// и выводит краткое описание каждой задачи на отдельной строке

func main() {
	// Считайте входные данные
	var bugID string
	var bugSeverity string
	var featureName string
	var featurePoints int
	var docTopic string

	fmt.Scanln(&bugID)
	fmt.Scanln(&bugSeverity)
	fmt.Scanln(&featureName)
	fmt.Scanln(&featurePoints)
	fmt.Scanln(&docTopic)

	// TODO: Создайте по одной задаче каждого типа (BugFix, Feature, Documentation)

	// TODO: Соберите все задачи в один срез []Task

	// TODO: Вызовите PrintBacklog, передав срез задач
}