24

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#?

Community
  • 1
Robert Harvey
  • 198,589
  • 55
  • 464
  • 673

1 Answers1

14

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.
Jimmy Hoffa
  • 16,039
  • 3
  • 69
  • 80
  • The utility of extension methods in Linq derives in large part by their ability to *graft a method implementation onto an interface,* in particular `IEnumerable` and `IQueryable`. While you could fake this with `static` methods in a utility class, it would be clumsy. – Robert Harvey May 08 '13 at 04:17
  • @RobertHarvey It's not necessarily accurate to claim it puts the method on an interface, note the difference between an actual method on an interface and an extension method: A method on an interface will be implemented inside of the class which implements that interface, and therefore has available access to a great deal more than any extension method does. Again it's a change in perspective, code implemented inside a class is given a special perspective compared to that outside. – Jimmy Hoffa May 08 '13 at 14:10