Как сделать интерфейс для иерархии типов?

Question

[Сергей Тихонов]

В проекте есть два типа - "группа" и "элемент". У группы есть метод "получить определенные элементы". Получаем что-то такое:

type element struct {}

func (el *element) doA() int {...}
func (el *element) doB() int {...}

type group struct {
    elements []*element
}

func (g *group) getElements() []*element {...}

И есть два сервиса, каждый из которых по-своему использует элементы групп. Первому от элементов нужен только метод doA, второму - doB. Идея, которая никак не выходит из головы, звучит так: "зачем передавать сервисам полную реализацию, если можно ограничиться интерфейсами, необходимыми самим сервисам?". Например, чтобы нельзя было просто так взять и вызвать из сервиса B метод doA.

Возникают интерфейсы:

type AElement interface {doA() int}
type BElement interface {doB() int}

type AGroup interface {
    getElements() []AElement
}
type BGroup interface {
    getElements() []BElement
}

Так вот, "*group" не удовлетворяет ни AGroup, ни BGroup, потому что у getElements различаются типы возвращаемого значения. Вопрос к знатокам паттернов и го: это совсем долбанутая идея, или всё-таки есть техническая возможность ограничить сервису доступ к функционалу элемента интерфейсом?

Comments

[rustler2000]

Очень идиоматичненько - "Accept interfaces return concrete types"

Единственное, что нет возможности сделать объект чтобы и AGroup и BGroup удовлетворял.

[Сергей Тихонов]

Отличное решение, жалко основную проблему не решает :)

[rustler2000]

Сергей Тихонов, никто не мешает дождаться генериков, и сделать возврат через указатель. Или если генерики позволят разные типы возвращать нормально. Или interface{} и type assertion

[Сергей Тихонов]

<Тут должна быть картинка ждуна, но мне лень ее искать>

[rustler2000]

Сергей Тихонов, type assertion вполне себе быстро работает

[Сергей Тихонов]

type assertions не устраивает, потому что в каждом месте, где предполагается использовать AElement или BElement, придется получать []interface{} и кастить его. Во-первых куча повторений возникает, во-вторых исходная идея про ограничение доступа интерфейсом реализовывается не в виде "есть только doA", а в виде "хочешь doA, хочешь doB - но не оба сразу".
Я еще поигрался с адаптерами, выполняющими все эти приведения типов на лету, но опять же, нужна иерархия адаптеров вместо иерархии интерфейсов.

[rustler2000]

Сергей Тихонов, doA или doB дословно означает что в функции оба типа известы, есть две переменные и есть брэнчь (if/switch). не прямой вызов со строгой типизацией и без брэнча не возможен. с темплейтами туда-сюда, но и то только в сторону увеличения брэнчей (хоть и не явных) но ни как ни коллапс. более менее гообразный псевдокод напиши, а то может это для питона\js вопрос :E.

[rustler2000]

rustler2000, хаха
```
type A interface {
Do() int
IsA() bool
}

type B interface {
Do() int
IsB() bool
}

type Do interface {
Do() int
}
```

[Сергей Тихонов]

rustler2000, вот придумал вменяемый пример:

package main

import (
	"fmt";
	"io";
	"bytes"
)

func New() io.ReadWriter {
	return bytes.NewBufferString("a_string")
}

func Read(r io.Reader) {
	buf := make([]byte, 1)
	r.Read(buf)
	fmt.Printf("Read '%s'\n", buf)
}

func Write(w io.Writer) {
	w.Write([]byte("X"))
	fmt.Printf("Written 'X'\n")
}

func ReadMany(list []io.Reader) {
	for _, r := range(list) {
		Read(r)
	}
}

func WriteMany(list []io.Writer) {
	for _, w := range(list) {
		Write(w)
	}
}

func main() {
	base := New()
	
	list := make([]io.ReadWriter, 1)
	list[0] = base
	fmt.Printf("%v\n", list)

	Write(base)
	Read(base)
	
	// cannot use list (type []io.ReadWriter) as type []io.Reader in argument to ReadMany
	// ReadMany(list)
	// cannot use list (type []io.ReadWriter) as type []io.Writer in argument to WriteMany
	// WriteMany(list)
}

Последние два вызова определенно не работают, и как передать в них list без копирования - ума ни приложу.

[rustler2000]

Сергей Тихонов, без копирования никак. Но можно с рефлек подшаманить и будет типа Write(adapt(list, Write))/call(Write, list). ну или пустой интерфейс. Но по любому это без генериков полностью не решить только во время исполнения.

Answer 1

[nrgian]

Проверять, какой интерфейс доступен, приводить к нему:

readyForUse, ok:= element.(AElement)
if ok {
     readyForUse.doA()
}

Сергей Тихонов Сергей Тихонов

type assertions не устраивает, потому что в каждом месте, где предполагается использовать AElement или BElement, придется получать []interface{} и кастить его. Во-первых куча повторений возникает, во-вторых исходная идея про ограничение доступа интерфейсом реализовывается не в виде "есть только doA", а в виде "хочешь doA, хочешь doB - но не оба сразу".

Не типы кастить, а именно что интерфейсы.

Comments

[Сергей Тихонов]

Но всё равно в каждом месте использования :(

[nrgian]

Сергей Тихонов,

Но всё равно в каждом месте использования :(

Странный ты.
Тебе нужно определенный интерфейс.
Тебе предлагается его указать (кастить) - и все.
Ты что же считаешь - программа должна сама себя писать, а не ты её?

[Сергей Тихонов]

nrgian, нет, я не считаю, что программа должна сама себя писать. Я пытаюсь понять, "странный" ли язык Go и можно ли с этим что-то сделать. Пока все ответы выглядят так: вместо того, чтобы написать инструкцию type assertion (любым приемлемым для языка способом) один раз, необходимо делать этот type assertion во всех ста-пятистах местах использования. Кнопки Ctrl, C и V будут рады. В принципе, решение есть: забить на интерфейсы, сделать все методы классов публичными и будь что будет; но если есть более аккуратное решение упомянутой проблемы, то почему бы им не воспользоваться? Но похоже, что Repeat Yourself из принципа DRY - это всё, на что способен Go в этой ситуации.

Кстати насчет "сама себя писать". Кодогенерация - это ли не решение всех проблем?

[nrgian]

Сергей Тихонов, бэкграунд у вас какой?

[Сергей Тихонов]

nrgian, python 10 лет + go полгода.

[nrgian]

Сергей Тихонов,
Я то думал такие требования у вас с Java/C++ с их полиморфизмом методов.

[nrgian]

Сергей Тихонов,

необходимо делать этот type assertion во всех ста-пятистах местах использования

А как вы иначе собираетесь вызывать эти методы?
Если у них разная сигнатура параметров?

Кастование интерфейса с условным оператором как раз и позволяет в одной ветке if/switch обрабатывать один интерфейс, а в другой ветке - другой интерфейс. Не взирая на разность параметров.

Если же сигнатура одинаковая - то интерфейс тоже может быть один и тот же.

[Сергей Тихонов]

nrgian, пытаюсь понять, на что больше должен быть похож "статически типизированный код" на Go.

[rustler2000]

nrgian, > Я то думал такие требования у вас с Java/C++ с их полиморфизмом методов.

Кстати да - в крестах тоже придется dynamic_cast делать или темплейты использовать

[nrgian]

Сергей Тихонов, ну а как бы вы сделали это в Python?

[Сергей Тихонов]

Ну, в питоне я вряд ли бы стал заморачиваться: есть конечно пакеты, вводящие интерфейсы, но тратить время на превращение утиной типизации в статическую я бы посчитал излишним.
Если бы припекло, сделал бы прокси, которые прокидывали бы доступ только к доступным из "интерфейса" методам.

[nrgian]

Сергей Тихонов,
я спросил об том как бы внутри кода вы обрабатывали разнородные параметры?
в Go предлагается ветвление - одна ветка, один вид интерфейса обрабатывает.
что бы вы сделали в Python?

[Сергей Тихонов]

Если обработка разных видов интерфейса одинаковая, то не делал бы абсолютно ничего для поддержки разных типов. Всё сводится к утиной типизации. Если разные типы надо обрабатывать по-разному, то есть куча паттернов проектирования, как это сделать, и ответ тут сильно зависит от условий задачи. Начиная от аналога switch/case и заканчивая всякими визиторами.

[nrgian]

Сергей Тихонов,

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

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

func MyFunc(a MyDarlingInterface) {

    a.DoIt()

}

А конкретно это из вашего примера:

func Write(w io.Writer) {
  w.Write([]byte("X"))
  fmt.Printf("Written 'X'\n")
}

func ReadMany(list []io.Reader) {
  for _, r := range(list) {
    Read(r)
  }
}

можно сделать через "...":

func MyFunc(a ...MyDarlingInterface) {
   for _, v:= range a {
      v.DoIt()
   }
}

и вызывать как

MyFunc(SingleParameter...)

или как
MyFunc(ArrayParameter)