1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Programmiersprache Go…

Verstehe ich nicht ganz...

  1. Thema

Neues Thema Ansicht wechseln


  1. Verstehe ich nicht ganz...

    Autor: twothe 04.08.20 - 09:25

    Also Go ist eine objektorientierte Sprache ohne Klassen und Vererbungen, bietet keinerlei funktionale Features, keine Generics, und auch sonst nichts besonderes, aber kann Nebenläufigkeit im Stil der 90er Jahre.... Warum genau war Go jetzt noch mal gut?

  2. Re: Verstehe ich nicht ganz...

    Autor: \pub\bash0r 04.08.20 - 09:30

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Also Go ist eine objektorientierte Sprache ohne Klassen und Vererbungen,
    > bietet keinerlei funktionale Features, keine Generics, und auch sonst
    > nichts besonderes, aber kann Nebenläufigkeit im Stil der 90er Jahre....
    > Warum genau war Go jetzt noch mal gut?

    * Du hast Composition statt Inheritance
    * Du hast implizite Interfaces mit denen du deutlich mehr abstrahieren kannst als in typischen anderen OOP Sprachen
    * Das besondere ist, dass es nichts besonderes hat. Einfach gehalten zu sein ist quasi das Feature.
    * Die Nebenläufigkeit mit Goroutines und Channels ist eigentlich ziemlich genial und ich sehe nicht, was daran "altbacken" wäre. Andere Sprachen implementieren sowas ja jetzt auch. Scheint also eher kopierwürdig als verachtenswürdig zu sein.

  3. Re: Verstehe ich nicht ganz...

    Autor: BlackSuit 04.08.20 - 11:34

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > twothe schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Also Go ist eine objektorientierte Sprache ohne Klassen und Vererbungen,
    > > bietet keinerlei funktionale Features, keine Generics, und auch sonst
    > > nichts besonderes, aber kann Nebenläufigkeit im Stil der 90er Jahre....
    > > Warum genau war Go jetzt noch mal gut?
    >
    > * Du hast Composition statt Inheritance
    > * Du hast implizite Interfaces mit denen du deutlich mehr abstrahieren
    > kannst als in typischen anderen OOP Sprachen
    > * Das besondere ist, dass es nichts besonderes hat. Einfach gehalten zu
    > sein ist quasi das Feature.
    > * Die Nebenläufigkeit mit Goroutines und Channels ist eigentlich ziemlich
    > genial und ich sehe nicht, was daran "altbacken" wäre. Andere Sprachen
    > implementieren sowas ja jetzt auch. Scheint also eher kopierwürdig als
    > verachtenswürdig zu sein.

    Implizite Interfaces sind solange super, bis man Mal im Interface etwas refactorieren darf.

  4. Re: Verstehe ich nicht ganz...

    Autor: twothe 04.08.20 - 11:58

    BlackSuit schrieb:
    --------------------------------------------------------------------------------
    > Implizite Interfaces sind solange super, bis man Mal im Interface etwas
    > refactorieren darf.

    Jap. Den Quatsch kenn ich schon aus Typescript, wenn dann mal wieder irgend ein Update von irgend einer Library kommt, ein Basis-Interface ändert, und auf ein mal hinten und vorne nichts mehr passt.

    Implizite bzw. versteckte Abhängigkeiten sind der Tod jedes längeren Projektes.

  5. Re: Verstehe ich nicht ganz...

    Autor: \pub\bash0r 04.08.20 - 12:46

    BlackSuit schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > twothe schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Also Go ist eine objektorientierte Sprache ohne Klassen und
    > Vererbungen,
    > > > bietet keinerlei funktionale Features, keine Generics, und auch sonst
    > > > nichts besonderes, aber kann Nebenläufigkeit im Stil der 90er
    > Jahre....
    > > > Warum genau war Go jetzt noch mal gut?
    > >
    > > * Du hast Composition statt Inheritance
    > > * Du hast implizite Interfaces mit denen du deutlich mehr abstrahieren
    > > kannst als in typischen anderen OOP Sprachen
    > > * Das besondere ist, dass es nichts besonderes hat. Einfach gehalten zu
    > > sein ist quasi das Feature.
    > > * Die Nebenläufigkeit mit Goroutines und Channels ist eigentlich
    > ziemlich
    > > genial und ich sehe nicht, was daran "altbacken" wäre. Andere Sprachen
    > > implementieren sowas ja jetzt auch. Scheint also eher kopierwürdig als
    > > verachtenswürdig zu sein.
    >
    > Implizite Interfaces sind solange super, bis man Mal im Interface etwas
    > refactorieren darf.

    Dafür hab ich ne IDE. Und was die nicht erwischt schlägt halt beim Kompilieren fehl.

  6. Re: Verstehe ich nicht ganz...

    Autor: BlackSuit 04.08.20 - 13:10

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > BlackSuit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > \pub\bash0r schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > twothe schrieb:
    > > >
    > >
    > ---------------------------------------------------------------------------
    >
    > >
    > > > -----
    > > > > Also Go ist eine objektorientierte Sprache ohne Klassen und
    > > Vererbungen,
    > > > > bietet keinerlei funktionale Features, keine Generics, und auch
    > sonst
    > > > > nichts besonderes, aber kann Nebenläufigkeit im Stil der 90er
    > > Jahre....
    > > > > Warum genau war Go jetzt noch mal gut?
    > > >
    > > > * Du hast Composition statt Inheritance
    > > > * Du hast implizite Interfaces mit denen du deutlich mehr abstrahieren
    > > > kannst als in typischen anderen OOP Sprachen
    > > > * Das besondere ist, dass es nichts besonderes hat. Einfach gehalten
    > zu
    > > > sein ist quasi das Feature.
    > > > * Die Nebenläufigkeit mit Goroutines und Channels ist eigentlich
    > > ziemlich
    > > > genial und ich sehe nicht, was daran "altbacken" wäre. Andere Sprachen
    > > > implementieren sowas ja jetzt auch. Scheint also eher kopierwürdig als
    > > > verachtenswürdig zu sein.
    > >
    > > Implizite Interfaces sind solange super, bis man Mal im Interface etwas
    > > refactorieren darf.
    >
    > Dafür hab ich ne IDE. Und was die nicht erwischt schlägt halt beim
    > Kompilieren fehl.

    Ja super, noch Mal bei jeder Implementierung von Hand vorbei schauen!

  7. Re: Verstehe ich nicht ganz...

    Autor: \pub\bash0r 04.08.20 - 13:33

    BlackSuit schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > ---------------------------------------------------------------------------
    > > Dafür hab ich ne IDE. Und was die nicht erwischt schlägt halt beim
    > > Kompilieren fehl.
    >
    > Ja super, noch Mal bei jeder Implementierung von Hand vorbei schauen!

    Wenn die IDE nicht refactoren kann, hast du auch bei C#, Java, C++ etc. keine Freude am Ändern von Interfaces. Und wenn sie es kann, gibt's nix von Hand vorbeizuschauen. Ich versteh deinen Punkt also nicht.

  8. Re: Verstehe ich nicht ganz...

    Autor: BlackSuit 04.08.20 - 13:36

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > BlackSuit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > \pub\bash0r schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > > Dafür hab ich ne IDE. Und was die nicht erwischt schlägt halt beim
    > > > Kompilieren fehl.
    > >
    > > Ja super, noch Mal bei jeder Implementierung von Hand vorbei schauen!
    >
    > Wenn die IDE nicht refactoren kann, hast du auch bei C#, Java, C++ etc.
    > keine Freude am Ändern von Interfaces. Und wenn sie es kann, gibt's nix von
    > Hand vorbeizuschauen. Ich versteh deinen Punkt also nicht.

    Wie soll die IDE bei implizt implementierten Interfaces erkennen, wo diese Implementiert werden und wo nur die Methode zufällig die gleiche Signatur hat?

  9. Re: Verstehe ich nicht ganz...

    Autor: \pub\bash0r 04.08.20 - 13:56

    BlackSuit schrieb:
    --------------------------------------------------------------------------------
    > \pub\bash0r schrieb:
    > ---------------------------------------------------------------------------
    > > Wenn die IDE nicht refactoren kann, hast du auch bei C#, Java, C++ etc.
    > > keine Freude am Ändern von Interfaces. Und wenn sie es kann, gibt's nix von
    > > Hand vorbeizuschauen. Ich versteh deinen Punkt also nicht.
    >
    > Wie soll die IDE bei implizt implementierten Interfaces erkennen, wo diese
    > Implementiert werden und wo nur die Methode zufällig die gleiche Signatur
    > hat?

    Stimmt. Hast recht. Hab aber auch beim Antworten selbst wieder im typischen Vererbungs-OOP-Pattern gedacht.

    Das Problem mit den Interfaces ergibt sich so nicht, weil eben nicht der deklarierende das Interface definiert, sondern der Nutzer.
    Du schreibst also eben nicht eine Bibliothek, die ein Interface definiert und exportiert, sondern du exportierst deine konkreten Implementierungen.
    Wenn ich deine Bibliothek nutze, und brauche nur einen Bruchteil daraus, definiere ich ein Interface dafür und hab somit dann die Möglichkeit, deine Implementierung durch eine eigene zu erweitern, zu wrappen, im Test zu ersetzen, was auch immer.
    Das Interface selbst zu refactoren macht da keinen Sinn. Wenn meine Anforderungen sich ändern, unterliege ich ja trotzdem den Constraints der "Objekte", die ich nutzen will. Das Interface stellt lediglich sicher, dass das Subset an Funktionen, das ich erwarte, auch erfüllbar ist.

    Es gibt auch Fälle, in denen die Interfaces sinnvoll innerhalb einer Bibliothek genutzt werden (net/http hat da ein paar Beispiele), da sind es aber jeweils so wenige stellen, dass man das beim Refactoring sieht. (In den Fällen, in denen man ein Interface selbst implementiert um "nach außen" eine Garantie abzugeben, kann man mit Type-Guards arbeiten. Ist aber wie gesagt eher die Ausnahme.)

    So grundlegende Abstraktionen wie `io.Reader` und `io.Writer` sind aber unglaublich mächtig. Und sowas vermisse ich in anderen Sprachen.

  10. Re: Verstehe ich nicht ganz...

    Autor: BlackSuit 04.08.20 - 15:39

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > BlackSuit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > \pub\bash0r schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > > Wenn die IDE nicht refactoren kann, hast du auch bei C#, Java, C++
    > etc.
    > > > keine Freude am Ändern von Interfaces. Und wenn sie es kann, gibt's nix
    > von
    > > > Hand vorbeizuschauen. Ich versteh deinen Punkt also nicht.
    > >
    > > Wie soll die IDE bei implizt implementierten Interfaces erkennen, wo
    > diese
    > > Implementiert werden und wo nur die Methode zufällig die gleiche
    > Signatur
    > > hat?
    >
    > Stimmt. Hast recht. Hab aber auch beim Antworten selbst wieder im typischen
    > Vererbungs-OOP-Pattern gedacht.
    >
    > Das Problem mit den Interfaces ergibt sich so nicht, weil eben nicht der
    > deklarierende das Interface definiert, sondern der Nutzer.
    > Du schreibst also eben nicht eine Bibliothek, die ein Interface definiert
    > und exportiert, sondern du exportierst deine konkreten Implementierungen.
    > Wenn ich deine Bibliothek nutze, und brauche nur einen Bruchteil daraus,
    > definiere ich ein Interface dafür und hab somit dann die Möglichkeit, deine
    > Implementierung durch eine eigene zu erweitern, zu wrappen, im Test zu
    > ersetzen, was auch immer.
    > Das Interface selbst zu refactoren macht da keinen Sinn. Wenn meine
    > Anforderungen sich ändern, unterliege ich ja trotzdem den Constraints der
    > "Objekte", die ich nutzen will. Das Interface stellt lediglich sicher, dass
    > das Subset an Funktionen, das ich erwarte, auch erfüllbar ist.
    >
    > Es gibt auch Fälle, in denen die Interfaces sinnvoll innerhalb einer
    > Bibliothek genutzt werden (net/http hat da ein paar Beispiele), da sind es
    > aber jeweils so wenige stellen, dass man das beim Refactoring sieht. (In
    > den Fällen, in denen man ein Interface selbst implementiert um "nach außen"
    > eine Garantie abzugeben, kann man mit Type-Guards arbeiten. Ist aber wie
    > gesagt eher die Ausnahme.)
    >
    > So grundlegende Abstraktionen wie `io.Reader` und `io.Writer` sind aber
    > unglaublich mächtig. Und sowas vermisse ich in anderen Sprachen.

    Ich sehe jetzt bei der Umkehrung des Problems keinen Gewinn in irgendeiner Hinsicht. Es verlagert nur das Problem. Wenn ich in der Implementierung irgendwas ändere stimmen die Interfaces nicht mehr und müssen händisch überarbeitet werden. Den Vorzug gegenüber definierten Intefaces die von der Link exportiert werden sehe ich nicht. Im Gegenteil hat hier der Nutzer zusätzlichen Aufwand die Interfaces zu schreiben.

  11. Re: Verstehe ich nicht ganz...

    Autor: \pub\bash0r 04.08.20 - 16:13

    BlackSuit schrieb:
    --------------------------------------------------------------------------------
    > Ich sehe jetzt bei der Umkehrung des Problems keinen Gewinn in irgendeiner
    > Hinsicht. Es verlagert nur das Problem. Wenn ich in der Implementierung
    > irgendwas ändere stimmen die Interfaces nicht mehr und müssen händisch
    > überarbeitet werden. Den Vorzug gegenüber definierten Intefaces die von der
    > Link exportiert werden sehe ich nicht. Im Gegenteil hat hier der Nutzer
    > zusätzlichen Aufwand die Interfaces zu schreiben.

    Sorry, ich krieg's nicht besser erklärt. Ich fürchte, man muss damit einfach gearbeitet haben, um es zu verstehen. (Naja, oder jemanden finden, der es erklären kann ^^.)

    Das ist auch das schwerste beim Umstieg (!) auf Go. Das Ablegen der Denkweise aus anderen OOP Sprachen. Das ist zumindest mir schwer gefallen. Jedenfalls kann ich jetzt in Go Probleme einfacher lösen als ich sie in Java, Kotlin oder C# lösen kann. Ein paar dieser Erkenntnisse lasse ich rückzu wieder in meinen Java/Kotlin Code einfließen. Aber letztlich ist es Geschmackssache.

    Was aber ziemlich sicher nicht funktioniert ist, mal kurz in Go reinschnuppern und dann Schlüsse ziehen. Also kann man natürlich machen, ist aber so, als beurteilt man ein Buch nur nach dem Umschlag (oder wie auch immer man das sinnvoll übersetzen mag :-)).

    Keiner zwingt dich (hoffe ich), Go zu lernen. Wenn du keinen Grund dazu siehst, mach es halt nicht. Wenn du neugierig auf andere Sprachen bist und darauf, deine Denkweisen zu erweitern, lohnt es sich. Allerdings musst du dafür vermutlich mehrere Tools/Services in Go schreiben, so dass du auch über verschiedene Problemchen stolperst und überhaupt dazu kommst, deine aus anderen Sprachen übertragenen Design-Pattern in Frage zu stellen.
    Denn natürlich kannst du viele der "üblichen" Pattern anwenden. Nur wird der Go Code dann unglaublich hässlich. Die Lösung ist aber dann nicht, Go zu verdammen, sondern über die Pattern nachzudenken. Und genau das ist mMn das Spannende ... denn durch sowas stellt man fest, dass man Pattern einsetzt, die vlt. gar nicht so toll oder universell sind, wie man dachte.

  12. Re: Verstehe ich nicht ganz...

    Autor: BlackSuit 04.08.20 - 17:04

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > BlackSuit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ich sehe jetzt bei der Umkehrung des Problems keinen Gewinn in
    > irgendeiner
    > > Hinsicht. Es verlagert nur das Problem. Wenn ich in der Implementierung
    > > irgendwas ändere stimmen die Interfaces nicht mehr und müssen händisch
    > > überarbeitet werden. Den Vorzug gegenüber definierten Intefaces die von
    > der
    > > Link exportiert werden sehe ich nicht. Im Gegenteil hat hier der Nutzer
    > > zusätzlichen Aufwand die Interfaces zu schreiben.
    >
    > Sorry, ich krieg's nicht besser erklärt. Ich fürchte, man muss damit
    > einfach gearbeitet haben, um es zu verstehen. (Naja, oder jemanden finden,
    > der es erklären kann ^^.)
    >
    > Das ist auch das schwerste beim Umstieg (!) auf Go. Das Ablegen der
    > Denkweise aus anderen OOP Sprachen. Das ist zumindest mir schwer gefallen.
    > Jedenfalls kann ich jetzt in Go Probleme einfacher lösen als ich sie in
    > Java, Kotlin oder C# lösen kann. Ein paar dieser Erkenntnisse lasse ich
    > rückzu wieder in meinen Java/Kotlin Code einfließen. Aber letztlich ist es
    > Geschmackssache.
    >
    > Was aber ziemlich sicher nicht funktioniert ist, mal kurz in Go
    > reinschnuppern und dann Schlüsse ziehen. Also kann man natürlich machen,
    > ist aber so, als beurteilt man ein Buch nur nach dem Umschlag (oder wie
    > auch immer man das sinnvoll übersetzen mag :-)).
    >
    > Keiner zwingt dich (hoffe ich), Go zu lernen. Wenn du keinen Grund dazu
    > siehst, mach es halt nicht. Wenn du neugierig auf andere Sprachen bist und
    > darauf, deine Denkweisen zu erweitern, lohnt es sich. Allerdings musst du
    > dafür vermutlich mehrere Tools/Services in Go schreiben, so dass du auch
    > über verschiedene Problemchen stolperst und überhaupt dazu kommst, deine
    > aus anderen Sprachen übertragenen Design-Pattern in Frage zu stellen.
    > Denn natürlich kannst du viele der "üblichen" Pattern anwenden. Nur wird
    > der Go Code dann unglaublich hässlich. Die Lösung ist aber dann nicht, Go
    > zu verdammen, sondern über die Pattern nachzudenken. Und genau das ist mMn
    > das Spannende ... denn durch sowas stellt man fest, dass man Pattern
    > einsetzt, die vlt. gar nicht so toll oder universell sind, wie man dachte.

    Ja das Argument habe ich schon öfter gehört: Man muss lange etablierte und erfolgreich eingesetzte Pattern aus jahrelanger Erfahrung vergessen um dann den seligen Weg des Go einzuschlagen. Das mag für viele der Weg zum Glück sein für mich der Beweis von Gos strukturellen Defiziten. Glücklicherweise sind für mich Programmiersprachen außerhalb der JVM nur ein Hobby.

  13. Re: Verstehe ich nicht ganz...

    Autor: \pub\bash0r 04.08.20 - 17:37

    BlackSuit schrieb:
    --------------------------------------------------------------------------------
    > Ja das Argument habe ich schon öfter gehört: Man muss lange etablierte und
    > erfolgreich eingesetzte Pattern aus jahrelanger Erfahrung vergessen um dann
    > den seligen Weg des Go einzuschlagen. Das mag für viele der Weg zum Glück
    > sein für mich der Beweis von Gos strukturellen Defiziten. Glücklicherweise
    > sind für mich Programmiersprachen außerhalb der JVM nur ein Hobby.

    Demnach würde ja aber auch jede funktionale Sprache ausscheiden, oder? Dort kommst du mit OOP Pattern auch nicht weiter. Wenn du ernsthaft glaubst, dass es nur einen richtigen Weg gibt und alles andere falsch ist, ist dein Horizont vermutlich nicht so weit, wie du glaubst.

    Java und C# sind nicht das Maß aller Dinge. Rust ebenso wenig. Go auch nicht. Haskell nicht.

    Allerdings bringen Go, Rust und Haskell (und Elixir, ...) wenigstens "neues" auf den Tisch, wohingegen die ganzen OOP Sprachen der C-Familie (C++, C#, Java, Kotlin, ...) halt doch irgendwo gleich sind und ähnliche Pattern fördern und ggf. fordern. Nur weil man sich an diese Pattern gewöhnt hat, weil man mit dieser Sprachfamilie arbeitet, heißt das nicht, dass es der heilige Gral ist.

  14. Re: Verstehe ich nicht ganz...

    Autor: BlackSuit 04.08.20 - 18:15

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > BlackSuit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Ja das Argument habe ich schon öfter gehört: Man muss lange etablierte
    > und
    > > erfolgreich eingesetzte Pattern aus jahrelanger Erfahrung vergessen um
    > dann
    > > den seligen Weg des Go einzuschlagen. Das mag für viele der Weg zum
    > Glück
    > > sein für mich der Beweis von Gos strukturellen Defiziten.
    > Glücklicherweise
    > > sind für mich Programmiersprachen außerhalb der JVM nur ein Hobby.
    >
    > Demnach würde ja aber auch jede funktionale Sprache ausscheiden, oder? Dort
    > kommst du mit OOP Pattern auch nicht weiter. Wenn du ernsthaft glaubst,
    > dass es nur einen richtigen Weg gibt und alles andere falsch ist, ist dein
    > Horizont vermutlich nicht so weit, wie du glaubst.
    >
    > Java und C# sind nicht das Maß aller Dinge. Rust ebenso wenig. Go auch
    > nicht. Haskell nicht.
    >
    > Allerdings bringen Go, Rust und Haskell (und Elixir, ...) wenigstens
    > "neues" auf den Tisch, wohingegen die ganzen OOP Sprachen der C-Familie
    > (C++, C#, Java, Kotlin, ...) halt doch irgendwo gleich sind und ähnliche
    > Pattern fördern und ggf. fordern. Nur weil man sich an diese Pattern
    > gewöhnt hat, weil man mit dieser Sprachfamilie arbeitet, heißt das nicht,
    > dass es der heilige Gral ist.

    Keine Sorge ich kenne genügend andere Programmiersprachen und Paradigmen. Und gerade deswegen lerne ich ja neue Sprachen um neue Pattern zu lernen. Aber bei Go habe ich außer radikale Einfachheit nichts entdeckt, was verglichen mit anderen Sprachen wirklich interessant ist. Und ich verfolge den Hype um die Sprache seit dem ersten Release ohne einen einzigen Artikel gelesen zu haben der mir als nicht Eingeweihtem erklärt warum eine ausgeschriebene for-loop besser ist als Filter Map reduce.

  15. Re: Verstehe ich nicht ganz...

    Autor: Das Osterschnabeltier 05.08.20 - 00:04

    \pub\bash0r schrieb:
    --------------------------------------------------------------------------------
    > BlackSuit schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > \pub\bash0r schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > > Dafür hab ich ne IDE. Und was die nicht erwischt schlägt halt beim
    > > > Kompilieren fehl.
    > >
    > > Ja super, noch Mal bei jeder Implementierung von Hand vorbei schauen!
    >
    > Wenn die IDE nicht refactoren kann, hast du auch bei C#, Java, C++ etc.
    > keine Freude am Ändern von Interfaces. Und wenn sie es kann, gibt's nix von
    > Hand vorbeizuschauen. Ich versteh deinen Punkt also nicht.

    Java (und inzwischen C#) haben default Methoden für die Evolution von Interfaces. So wurden auch Streams in Java nachträglich dem List interface hinzugefügt. Ist also somit absolut mühelos. Default Methoden bringen zudem auch so DRY.

    Go bietet in dem Fall nichts dergleichen an?

  16. Re: Verstehe ich nicht ganz...

    Autor: \pub\bash0r 05.08.20 - 08:41

    Das Osterschnabeltier schrieb:
    --------------------------------------------------------------------------------
    > Java (und inzwischen C#) haben default Methoden für die Evolution von
    > Interfaces. So wurden auch Streams in Java nachträglich dem List interface
    > hinzugefügt. Ist also somit absolut mühelos. Default Methoden bringen zudem
    > auch so DRY.
    >
    > Go bietet in dem Fall nichts dergleichen an?

    Nein, aber das würde auch nicht passen, da du Interfaces in Go nicht so verwendest. In Go liegt der Schwerpunkt des Interfaces bei seinem Benutzer, nicht bei dem, der die Funktionalität implementiert. Der weiß meist gar nichts von dem Interface. Ich versuch mal ein Beispiel zu bringen:

    Sagen wir du implementierst einen data access layer und möchtest (natürlich) dependency injection anwenden, um die eigentliche SQL Ausführung zu testen oder auszublenden oder was auch immer.

    In *deinem* DAO brauchst du nur eine Funktionalität zum SQL Layer: nämlich Query ausführen. Also definierst du:

    type QueryExecuter interface {
    Exec(query string, args ...interface{}) (db.Result, error)
    }

    Sprich: du verlangst, dass was auch immer man dort injected, in der Lage ist, `Exec(query, args)` auszuführen und dir in Folge ein Resultset zu geben.

    Wie der "Zufall" so will, stellt das Standard Library Package `db` dir bereits eine "Klasse" zur Verfügung, die *unter anderem* diese Methode implementiert. Also kannst du mit jedem Standard SQL Treiber bereits das Interface erfüllen ... ohne, dass diese (Third Party!) packages etwas von deinem Interface wissen. Go prüft nur auf der Zuweisungs-Seite.

    Ein anderes Beispiel, wo eine Bibliothek (nämlich die stdlib) ein Interface nutzt, ist im `io` Umfeld. Dort gibt es z.B.

    type Reader interface {
    Read(p []byte) (n int, err error)
    }
    type Writer interface {
    Write(p []byte) (n int, err error)
    }

    Sprich: jeder der `Read...` implementiert erfüllt automatisch `io.Reader` und jeder der `Write...` implementiert erfüllt automatisch `io.Writer`.

    Nimmst du jetzt also eine Funktion wie `func Copy(dst Writer, src Reader) (written int64, err error)`, kannst du von beliebigen Readern in beliebiger Writer schreiben. Soweit klar. Die Auswirkung dieser einfachen Interfaces und des impliziten Type-Checks sind aber ziemlich weit. Denn wie gesagt erfüllt ja jeder, der einfach nur ein wie oben beschriebenes `Read` implementiert den `Reader` und analog mit Write. Sprich: eine Datei ist ein Reader (und ggf. Writer), ebenso eine Network Connection ... aber auch eine Hash Methode.

    Ergo: du willst eine Datei hashen? (leicht vereinfacht)

    f := os.Open("myFile.irgendwas")
    s := sha256.New()
    io.Copy(s, f)

    ---

    Btw. können in Go nicht nur "structs" Interfaces erfüllen. Sondern alles, was Methoden implementiert. Und das sind alle Typen. Du kannst einen Type-Alias auf einen `int32`definieren und dem dann Methoden verpassen. Schon erfüllt der (ggf.) ein Interface.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Stiftung Hospital zum heiligen Geist, Frankfurt am Main
  2. CompuGroup Medical SE & Co. KGaA, Rodgau, Frankfurt, Wiesbaden, Mainz, Mannheim (Home-Office)
  3. enowa AG, verschiedene Standorte
  4. ESG InterOp Solutions GmbH, Wilhelmshaven, Koblenz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Mobile-Angebote
  1. 369,99€ (Bestpreis!)
  2. 789€ (mit Rabattcode "PRIMA10" - Bestpreis!)
  3. 206,10€ (mit Rabattcode "PFIFFIGER" - Bestpreis!)
  4. 689€ (mit Rabattcode "PRIMA10" - Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Thinkpad Trackpoint Keyboard 2 im Test: Tolle kompakte Tastatur für Thinkpad-Fans
Thinkpad Trackpoint Keyboard 2 im Test
Tolle kompakte Tastatur für Thinkpad-Fans

Lenovos externe Thinkpad-Tastatur bietet alle Vorteile der Tastatur eines Thinkpad-Notebooks. Sie arbeitet drahtlos und mit Akkutechnik.
Ein Test von Ingo Pakalski

  1. Thinkpad X1 Fold Das faltbare Thinkpad kommt im Oktober
  2. Thinkpad X1 Nano Lenovo macht das Carbon winzig
  3. Thinkpad E14 Gen2 (AMD) im Test Gelungener Ryzen-Laptop für 700 Euro

Tutorial: Was ein On Screen Display alles kann
Tutorial
Was ein On Screen Display alles kann

Werkzeugkasten Viele PC-Spieler schwören auf ein OSD. Denn damit lassen sich Limits erkennen, die Bildqualität verbessern und Ruckler verringern.
Von Marc Sauter


    IT-Jobs: Die schwierige Suche nach dem richtigen Arbeitgeber
    IT-Jobs
    Die schwierige Suche nach dem richtigen Arbeitgeber

    Nur jeder zweite Arbeitnehmer ist mit seinem Arbeitgeber zufrieden. Das ist fatal, weil Unzufriedenheit krank macht. Deshalb sollte die Suche nach dem passenden Job nicht nur dem Zufall überlassen werden.
    Von Peter Ilg

    1. Digitalisierung in Firmen Warum IT-Teams oft übergangen werden
    2. Jobs Unternehmen können offene IT-Stellen immer schwerer besetzen
    3. Gerichtsurteile Wann fristlose Kündigungen für IT-Mitarbeiter rechtens sind