In che modo Go migliora la produttività con interfacce "implicite" e come si confronta con la nozione di metodi di estensione di C #?

Nel Go Language Tutorial, spiegano come funzionano le interfacce:

Go non ha classi. Tuttavia, è possibile definire metodi su tipi di struttura. Il destinatario del metodo appare nel proprio elenco di argomenti tra la parola chiave func e il nome del metodo.

type Vertex struct {
    X, Y float64
}

func (v *Vertex) Abs() float64 {
    return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

Un tipo di interfaccia è definito da una serie di metodi. Un valore di tipo di interfaccia può contenere qualsiasi valore che implementa tali metodi.

Questo è l'unico modo per creare un'interfaccia in Go. Google spiega inoltre che:

Un tipo implementa un'interfaccia implementando i metodi. Non esiste una dichiarazione esplicita di intenti [ad esempio interfacedichiarazioni].

Le interfacce implicite separano i pacchetti di implementazione dai pacchetti che definiscono le interfacce: nessuno dei due dipende dall'altro.

Incoraggia anche la definizione di interfacce precise, perché non è necessario trovare tutte le implementazioni e contrassegnarle con il nome della nuova interfaccia.

Tutto ciò suona sospettosamente come metodi di estensione in C # , tranne per il fatto che i metodi in Go sono spietatamente polimorfici; opereranno su qualsiasi tipo che li implementa.

Google afferma che ciò incoraggia un rapido sviluppo, ma perché? Rinunci a qualcosa allontanandoti da interfacce esplicite in C #? I metodi di estensione in C # potrebbero consentire di trarre alcuni dei vantaggi che le interfacce Go hanno in C #?

Non vedo affatto i metodi di estensione e le interfacce implicite uguali.

Per prima cosa parliamo allo scopo.

I metodi di estensione esistono come uno zucchero sintattico specifico per darti la possibilità di usare un metodo come se fosse un membro di un oggetto, senza avere accesso agli interni di quell'oggetto. Senza i metodi di estensione puoi fare esattamente la stessa cosa, semplicemente non ottieni la piacevole sintassi di someObjectYouCantChange.YourMethod()e piuttosto devi chiamare YourMethod(someObjectYouCantChange).

Lo scopo delle interfacce implicite è tuttavia quello di poter implementare un'interfaccia su un oggetto a cui non si ha accesso al cambiamento. Questo ti dà la possibilità di creare una relazione polimorfica tra qualsiasi oggetto che scrivi e qualsiasi oggetto di cui non hai accesso agli interni.

Ora parliamo delle conseguenze.

I metodi di estensione non ne hanno davvero nessuno, questo è perfettamente in linea con gli spietati vincoli di sicurezza che .NET tenta di utilizzare per aiutare in distinte prospettive su un modello (la prospettiva dall'interno, dall'esterno, dall'erede e dal vicino). La conseguenza è solo una piacevolezza sintattica.

Le conseguenze delle interfacce implicite sono alcune cose.

• Implementazione accidentale dell'interfaccia, questo può essere un incidente felice o una violazione accidentale di LSP incontrando l'interfaccia di qualcun altro che non avevi intenzione di non onorare l'intenzione del suo contratto.
• La capacità di fare in modo che qualsiasi metodo accetti una beffa di un dato oggetto semplicemente rispecchiando l'interfaccia di quegli oggetti (o anche semplicemente creando un'interfaccia che soddisfi i requisiti di tali metodi e non di più).
• La capacità di creare adattatori o altri vari schemi simili con maggiore facilità per quanto riguarda gli oggetti di cui non si può intromettersi.
• Ritarda l'implementazione dell'interfaccia e implementala in un secondo momento senza dover toccare l'implementazione effettiva, implementandola solo quando desideri effettivamente creare un altro implementatore.