Come migliora la produttività con interfacce "implicite" e come si confronta con la nozione di metodi di estensione di C #?

Question

Come migliora la produttività con interfacce "implicite" e come si confronta con la nozione di metodi di estensione di C #?

#1 da (11 voti)

20

Nell'esercitazione Go Language, spiegano come funzionano le interfacce:

Go does not have classes. However, you can define methods on struct types. The method receiver appears in its own argument list between the func keyword and the method name.

type Vertex struct {
    X, Y float64
}

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

An interface type is defined by a set of methods. A value of interface type can hold any value that implements those methods.

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

A type implements an interface by implementing the methods. There is no explicit declaration of intent [i.e. interface declarations].

Implicit interfaces decouple implementation packages from the packages that define the interfaces: neither depends on the other.

It also encourages the definition of precise interfaces, because you don't have to find every implementation and tag it with the new interface name.

Tutto ciò sembra sospetto come Metodi di estensione in C # , ad eccezione dei metodi in Go sono spietatamente polimorfici; funzioneranno su qualsiasi tipo che li implementa.

Google sostiene che ciò incoraggi un rapido sviluppo, ma perché? Ti arrendi qualcosa spostandoti da interfacce esplicite in C #? I Metodi di estensione in C # possono consentire di ricavare alcuni dei vantaggi che le interfacce Go hanno in C #?

c# language-design go

posta Robert Harvey 08.05.2013 - 01:55

fonte

1 risposta

Leggi altre domande sui tag c# language-design go

Il modo migliore per implementare l'autenticazione per un'API REST Esistono notevoli esempi di disastri aziendali direttamente attraenti per software open source? [chiuso]

score 11 · Accepted Answer

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

Per prima cosa parliamo allo scopo.

I metodi di estensione esistono come zucchero sintattico specificamente 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, non ottieni la sintassi piacevole di someObjectYouCantChange.YourMethod() e devi chiamare YourMethod(someObjectYouCantChange) .

Lo scopo delle interfacce implicite è tuttavia che è possibile implementare un'interfaccia su un oggetto a cui non si ha accesso per cambiare. Questo ti dà la possibilità di creare una relazione polimorfica tra qualsiasi oggetto che scrivi tu stesso e qualsiasi oggetto per il quale non hai accesso agli interni.

Ora parliamo delle conseguenze.

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

Le conseguenze delle interfacce implicite sono alcune cose.

Implementazione accidentale dell'interfaccia, questo può essere un felice incidente o una violazione accidentale di LSP incontrando l'interfaccia di qualcun altro che non intendevi mentre non rispettava l'intento del suo contratto.
La possibilità di rendere facilmente qualsiasi metodo accetta una simulazione di qualsiasi oggetto dato semplicemente rispecchiando l'interfaccia degli oggetti (o anche solo creando un'interfaccia che soddisfi i requisiti dei metodi e non più).
La possibilità di creare adattatori o altri modelli simili con maggiore facilità rispetto agli oggetti che non puoi intromettersi nelle viscere di.
Implementare l'implementazione dell'interfaccia e implementarla in seguito senza dover toccare l'implementazione effettiva, implementandola solo quando si desidera effettivamente creare un altro implementor.