Go vs. C# – How Go’s Implicit Interfaces Improve Productivity Compared to C# Extension Methods

cgolanguage-design

In the Go Language Tutorial, they explain how interfaces work:

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.

This is the only way to create an interface in Go. Google further explains that:

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.

This all sounds suspiciously like Extension Methods in C#, except that methods in Go are ruthlessly polymorphic; they will operate on any type that implements them.

Google claims that this encourages rapid development, but why? Do you give up something by moving away from explicit interfaces in C#? Could Extension Methods in C# allow one to derive some of the benefits that Go interfaces have in C#?

Best Answer

I don't see extension methods and implicit interfaces as the same at all.

First let's speak to purpose.

Extension methods exist as a syntactic sugar specifically to give you the ability to use a method as if it's a member of an object, without having access to the internals of that object. Without extension methods you can do exactly the same thing, you just don't get the pleasant syntax of someObjectYouCantChange.YourMethod() and rather have to call YourMethod(someObjectYouCantChange).

The purpose of implicit interfaces however is so that you can implement an interface on an object you don't have access to change. This gives you the ability to create a polymorphic relationship between any object you write yourself and any object you don't have access to the internals of.

Now let's speak to consequences.

Extension methods really have none, this is perfectly in line with the ruthless security constraints .NET tries to use to aid in distinct perspectives on a model (the perspective from inside, outside, inheritor, and neighbor). The consequence is just some syntactic pleasantness.

The consequences of implicit interfaces are a few things.

  • Accidental interface implementation, this can be a happy accident, or an accidental LSP violation by meeting someone else's interface which you didn't intend to while not honoring the intent of it's contract.
  • The ability to easily make any method accept a mock of any given object at all by simply mirroring that objects interface (or even just creating an interface that meets that methods requirements and no more).
  • The ability to create adapters or other various similar patterns with more ease in regards to objects you can't meddle at the innards of.
  • Delay interface implementation, and implement it later without having to touch the actual implementation, only implementing it when you actually want to create another implementor.
Related Topic