slice struct != Scheibe der Schnittstelle implementiert?

Habe ich eine Schnittstelle Model implementiert durch struct Person.

Um ein Modell-Beispiel habe ich die folgenden Hilfsfunktionen:

func newModel(c string) Model {
    switch c {
    case "person":
        return newPerson()
    }
    return nil
}

func newPerson() *Person {
    return &Person{}
}

Dem obigen Ansatz ermöglicht es mir, um wieder eine richtig getippte Person-Instanz (kann leicht hinzufügen neuer Modelle später mit dem gleichen Ansatz).

Wenn ich versuchte, etwas ähnliches zu tun für die Rücksendung eine Scheibe von Modellen, bekomme ich eine Fehlermeldung. Code:

func newModels(c string) []Model {
    switch c {
    case "person":
        return newPersons()
    }
    return nil
}

func newPersons() *[]Person {
    var models []Person
    return &models
}

Gehen, beschwert sich mit: cannot use newPersons() (type []Person) as type []Model in return argument

Mein Ziel ist die Rückgabe einer Scheibe was auch immer das Modell, der Typ wird verlangt (ob []Person, []FutureModel, []Terminator2000, w/e). Was bin ich, und wie kann ich richtig die Implementierung einer solchen Lösung?

  • Ein Segment unterscheidet sich von einem array in Gehen. Da waren Sie wirklich sprechen, Scheiben, habe ich Ihren Beitrag bearbeitet um dies zu reflektieren.
  • Stephen, vielen Dank, geschätzt 🙂
  • Haben Sie jemals herausfinden? Ich bin versucht, das gleiche zu tun, so dass ich nicht wiederholen Sie eine Tonne von code für meine /api/{collection}. Ich habe es funktioniert für alles, außer für die index-Funktion, die Lesen muss in eine Scheibe.
  • Ich kann mich nicht erinnern, was ich am Ende tun hier, und ich habe nicht gespielt w/ Gehen in eine Weile. Sorry, ich kann nicht mehr Hilfe.
  • Kontravarianz (oder ist das Kovarianz -?) schlägt wieder zu!
InformationsquelleAutor Jon L. | 2012-10-21
  1. 85

    Dies ist sehr ähnlich zu einer Frage, die ich gerade beantwortet: https://stackoverflow.com/a/12990540/727643

    Die kurze Antwort ist, dass Sie korrekt sind. Eine Scheibe von Strukturen ist nicht gleich eine Scheibe ein interface struct implementiert.

    Einen []Person und ein []Model haben unterschiedliche Speicher-layouts. Dies ist, weil die Art, Sie sind die Scheiben haben unterschiedliche Speicher-layouts. Ein Model ist ein interface-Wert, was bedeutet, dass im Speicher es ist zwei Worte, die in der Größe. Ein Wort für die Art von Informationen, die andere für die Daten. Ein Person ist eine Struktur, deren Größe hängt von der darin enthaltenen Felder. Um die Konvertierung von []Person zu einem []Model, müssen Sie die Schleife über das array und nicht eine Typ-Konvertierung für jedes element.

    Seit dieser Umstellung ist eine O(n) Betrieb und würde in eine neue Scheibe erstellt, Gehen Sie weigert sich, es zu tun, implizit. Sie können es tun, explizit mit dem folgenden code.

    models := make([]Model, len(persons))
for i, v := range persons {
    models[i] = Model(v)
}
return models

    Und als dskinner hingewiesen, werden Sie wahrscheinlich wollen ein Stück von Zeigern und nicht einen Zeiger auf eine Scheibe. Ein Zeiger auf einer Scheibe ist normalerweise nicht erforderlich.

    *[]Person        //pointer to slice
[]*Person        //slice of pointers
    • Wusste nicht, zu der Zeit, aber meine Antwort nicht direkt auf die aufgeworfene Frage. Diese Antwort-Adressen.
    • Sehr nette Antwort, insbesondere mit der Erklärung über die Anzahl der Worte der Erinnerung für jeden Typ
    • github.com/golang/go/wiki/InterfaceSlice
    • Auch wie du schreibst etwas in eine abstrakte, generische Weise dann? Stellen Sie sich vor Sie haben 100 K-Ergebnisse aus einer Datenbank-Abfrage und Sie haben Durchlaufen Sie alle und erstellen Sie eine Kopie jedes Datensatzes ist. Das heißt, Sie können nicht generische interfaces in Go
    • Deine Antwort ist richtig, aber die Erklärung hat mir zu denken gegeben, dass, wenn ich hatte eine Schnittstelle A die Umsetzung der von mir gewünschten Schnittstelle B ich wäre in der Lage zu verwenden, eine Scheibe As, als eine Scheibe Bs (nach allen, die Speicher-Struktur ist identisch, da Sie beide Schnittstellen). Ich war enttäuscht zu entdecken, ich kann nicht 🙁
    • Schnittstelle A und Schnittstelle B haben unterschiedliche vtables. So ist es nicht ganz das gleiche layout im Speicher. Wenn es behandelt Schnittstelle die gleiche Weise behandelt, Schnittstelle B, Sie könnten versuchen, führen Sie die falsche Funktion. Sie können verwenden Sie unsicher.Zeiger auf das ausprobieren selbst. Es wäre ein Interessantes experiment!

    InformationsquelleAutor Stephen Weinberg
  2. 8

    Vielleicht ist das ein Problem mit dem Rückgabetyp *[]Person, wo Sie eigentlich sein sollten []*Person so zu verweisen, dass jeder index, der slice ist eine Referenz auf ein Person, und wo eine Scheibe [] ist in sich eine Referenz auf ein array.

    Schauen Sie sich das folgende Beispiel:

    package main

import (
    "fmt"
)

type Model interface {
    Name() string
}

type Person struct {}

func (p *Person) Name() string {
    return "Me"
}

func NewPersons() (models []*Person) {
    return models
}

func main() {
    var p Model
    p = new(Person)
    fmt.Println(p.Name())

    arr := NewPersons()
    arr = append(arr, new(Person))
    fmt.Println(arr[0].Name())
}
    • Danke für die Antwort. Während (wie Sie angemerkt haben), das es nicht direkt ansprechen, die Frage auf der hand, es ist ein würdiges Beispiel trotzdem 🙂
    InformationsquelleAutor dskinner
  3. 7

    Als Stephen die Frage bereits beantwortet und du bist ein Anfänger ich betonen, auf zu beraten.

    Einen besseren Weg, von der Arbeit mit go-Schnittstellen nicht über einen Konstruktor verfügen, der Rückkehr
    die Schnittstelle, wie Sie eingesetzt werden könnten, um von anderen Sprachen, wie java, aber haben
    ein Konstruktor für jedes Objekt, unabhängig, wie Sie die Schnittstelle implementieren implizit.

    Statt

    newModel(type string) Model { ... }

    sollten Sie tun

    newPerson() *Person { ... }
newPolitician() *Politician { ... }

    mit Person und Politician sowohl die Umsetzung der Methoden der Model.
    Sie können immer noch Person oder Politician überall, wo Model
    ist akzeptiert, aber Sie können auch andere Schnittstellen implementieren.

    Mit Ihrer Methode würden Sie begrenzt Model bis Sie eine manuelle Umstellung auf
    eine weitere Schnittstelle geben.

    Angenommen ich habe eine Person implementiert die Methode Walk() und ein Model implementiert ShowOff() folgende nicht funktionieren würde, geradlinig:

    newModel("person").ShowOff()
newModel("person").Walk() //Does not compile, Model has no method Walk

    Allerdings würde dies:

    newPerson().ShowOff()
newPerson().Walk()
    • Du hast Recht 🙁 Mein Ansatz ist der Versuch, zu generisch bieten Zugang zu Modellen, die über eine ReST-API. So eine Anfrage /api/{collection} dynamisch interagieren w/ die angeforderte Sammlung. Können Sie vorschlagen, eine alternative Lösung ohne explizit die Prüfung der angeforderten Auflistung über mehrere Funktionen? Ich denke, was ich Suche, ist ein Weg, um anzugeben, ein generischer Rückgabetyp, ohne Verlust von know-how der it-Typ.
    • Kenntnisse der Typ ist immer erhalten, auch wenn Sie zurück interface{}, das problem ist, dass Sie dann tun müssen, runtime-type-Behauptungen anstelle von compiler Typ-überprüfung. Eine generische Lösung für name -> object ohne Laufzeit Behauptungen ist nur möglich, die Verwendung von Generika, die gehen nicht unterstützt. Also, wenn Sie dies tun, Sie haben zu Leben, mit Reflexions-oder die Nachteile Ihrer Lösung.
    • Punkt [] - Modell != []Person oder sogar die [] - Modell != []Politiker. Das ist das Problem.
    • Richtig. Ich erwähne dies an der Spitze meiner Antwort: diese Antwort gibt Ergänzende Informationen bezüglich der Eingabe und gehen-Schnittstelle Konventionen, die die OP nicht zu wissen scheinen, aber die akzeptierte Antwort nicht angesprochen.
    InformationsquelleAutor nemo
  4. 2

    Typen T und []T, sind verschiedene Arten und verschiedene sind Ihre Methoden, auch wenn die Befriedigung der gleichen Schnittstelle. IOW, jede Art befriedigend Modell implementieren müssen alle sich das Modell der Methoden von selbst - die Methode receiver kann nur einen bestimmten Typ.

    InformationsquelleAutor zzzz
  5. 2

    Als andere haben schon geantwortet, []T ist ein eigener Typ. Ich möchte nur hinzufügen, dass eine einfache Dienstprogramm kann verwendet werden, konvertieren Sie generisch.

    import "reflect"

//Convert a slice or array of a specific type to array of interface{}
func ToIntf(s interface{}) []interface{} {
    v := reflect.ValueOf(s)
    //There is no need to check, we want to panic if it's not slice or array
    intf := make([]interface{}, v.Len())
    for i := 0; i < v.Len(); i++ {
        intf[i] = v.Index(i).Interface()
    }
    return intf
}

    Nun, Sie können es verwenden, wie diese:

    ToIntf([]int{1,2,3})
    InformationsquelleAutor slavikm
  6. 2

    Gehen, auch wenn die Umsetzung erlaubt dies, es ist leider ungesund: Sie können nicht zuordnen []Person auf eine variable vom Typ []Model weil ein []Model hat unterschiedliche Fähigkeiten. Zum Beispiel, nehmen wir an, wir haben auch Animal implementiert Model:

    var people []Person = ...
var models []Model = people //not allowed in real Go
models[0] = Animal{..} //???
var person Person = people[0] //!!!

    Wenn wir zulassen, dass Zeile 2, dann Zeile 3 sollte auch funktionieren, da models können sehr gut speichern Animal. Und Zeile 4 sollte weiterhin funktionieren, da people speichert Persons. Aber dann haben wir am Ende eine variable vom Typ Person hält eine Animal!

    Java tatsächlich erlaubt die Entsprechung von Zeile 2, und es ist weithin als ein Fehler. (Der Fehler ist gefangen im Lauf der Zeit; die Linie 3 würde werfen ein ArrayStoreException.)

    InformationsquelleAutor Luke Maurer
Schreibe einen Kommentar