Comment by kasey_junk | Hacker News Reader

Comment by kasey_junk | Hacker News Reader

Parent Full thread

I am fairly consistent in my criticism of Go. I am also fairly consistent in my insistence that the Dependency Inversion Principle is one of the harder concepts to wrap your head around of the SOLID principles (not least because several other concepts use terms similar).

But golang's structural typing actually allows for some of the easiest demonstrations of the implementation of the DIP of any of the strongly typed languages I've used.

I find Martin's definition of the DIP counterintuitive. A description that makes more sense to me is "interfaces should be defined by the 'users' of the interface, not by the implementers".

With a language like C++ or Java, to achieve this requires either lots of adapter layers or compiler tricks. With golang it is simple.

As a for instance, let's say I'm writing a restful client library for a specific application. It is tempting to to hard code a dependency on the std lib http.Client.Do method. If instead with 3 lines of code, I define my own interface for Do that matches the std library definition. I can use the std library, or any other library that matches it (one that is faster say or implements back off).

That is one of the few areas where the golang type system is pretty cool in comparison to its peers.

But with Go's system you can't provide an implementation of an interface for a type unless you defined that type in your package. You have to use an adapter layer for that. (For example, say I want to make an interface with a function "func Show() string" that prints debug information about a type--I can't implement that function directly on http.Client, only on an e.g. "type MyClient = http.Client" wrapper.) So that makes it harder to achieve loose coupling, because you can't make your own interfaces that unify standard library types and your types unless you make your types take exactly the same methods with exactly the same signatures (problematic if you want your types to support slightly different functionality, etc.)

In a system that allows you to implement interfaces for types that you didn't define in your package, there is a little more boilerplate necessary compared to Go, but only a few lines necessary to achieve the exact same effect. In pseudo-Go:

    type Do interface {
        func Do(req *Request) (*Response, error)
    }

    // boilerplate
    implement Do for http.Client {
        func (c *Client) Do(req *Request) (*Response, error) {
            return c.Do(req) // call stdlib implementation
        }
    }

    // custom implementation of Do
    implement Do for MockClient { ... }

So Go makes a tradeoff with its structural typing: it doesn't require the small amount of boilerplate code to achieve the pattern you describe, but it prevents you from providing new implementations for types you didn't define. Reasonable people can differ as to whether the side of the tradeoff Go makes encourages or discourages loose coupling.

I think you're a little off. The only boilerplate required for your example is the interface definition. After that you can define your own implementations of the "Do" interface as suggested by the parent.

  // boilerplate
  type Do interface {
    func Do(*http.Request) (*http.Response, error)
  }

  // Custom Implementation
  type MockClient struct {}
  func (mc *MockClient) Do(req *http.Request) (*http.Response, error) {
    // MockClient type now satisfies the Do interface
  }

You're not taking this issue in account:

> you can't make your own interfaces that unify standard library types and your types unless you make your types take exactly the same methods with exactly the same signatures (problematic if you want your types to support slightly different functionality, etc.)

The original comment mentioned being able to decouple Go code from specific implementations of functionality by relying on self defined interfaces instead of specific functions. pcwalton's example seemed to confuse this point, which I wanted to clarify.

As to that point, your interface types will only match standard library ones if you're trying to unify them. In which case you probably want them to have the same signature.

> The original comment mentioned being able to decouple Go code from specific implementations of functionality by relying on self defined interfaces instead of specific functions. pcwalton's example seemed to confuse this point, which I wanted to clarify.

The problem is that you're clarifying the wrong thing, the example is confusing because it trivially proxies a built-in method but the remark is what's important to the reply. Your reply is only confusing things further by considering the flawed example but ignoring the actual point.

> As to that point, your interface types will only match standard library ones if you're trying to unify them.

No, why would you think that? You may want to "compatibilise" multiple third-party types (that some of them are in the standard library is a complete red herring) as well as first-party ones (a mock or whatever) e.g. abstract over stdlib sockets, zmq sockets and sqlite.

You're right, I'm confusing the issue. I re-read pcwalton's comment and I think understand the point they're trying to make. Not sure the last part was correct though.

> So Go makes a tradeoff with its structural typing: it doesn't require the small amount of boilerplate code to achieve the pattern you describe, but it prevents you from providing new implementations for types you didn't define.

Shouldn't this be "So Go makes a tradeoff with its structural typing: it does require a small amount of boilerplate code to achieve the pattern you describe, but it allows you to provide new implementations for types you define."?

Well no because "the pattern you describe" in that context was only implementing stuff on types you own/control, which is basically a function declaration in Go, the problem is that doesn't extend to types you don't control, Go only lets you define methods on local types (types from the same package).

By comparison the code pcwalton shows has more upfront boilerplate, you need to explicitly `implement $Interface for $Type`, but it works for both local and non-local types.

That's what e.g. Rust does, you can implement a trait on a type if either the trait or the type is local (in theory you could also do so if neither is local but IIRC that's not allowed so conflicts don't have to be handled). Which means you can do this:

    trait Do {
        fn do(&self, req: &Request) -> Result<Response>
    }

    impl Do for hyper::http::Client {
        fn do(&self, req: &Request) -> Result<Response> {
            ...
        }
    }

    impl Do for MockClient {
        fn do(&self, req: &Request) -> Result<Response> {
            ...
        }
    }

There's a higher up-front syntactic cost (in that you have to declare the trait and you have to explicitly implement it even on the local MockClient type) but in return you also can implement it on the non-local "actual" http client.

Is there any reason Go couldn't allow defining methods on types defined in another package? It seems like you could allow that, gain the property you want, and still have structural typing.

The confusing thing about this if you did implement it, is if you import a package B that implements more methods for a type in package A, do those methods magically become available to you?

One of the nicest properties about Go currently IMO is that it's always very, very clear where things are defined.

Is there a tradeoff between structural typing and allowing the addition of functions to types defined outside of your package?

They seem like orthogonal concerns to me, but maybe they aren't?

TypeScript also does this. It's neat.

Reply on news.ycombinator.com