4 ms·

I don't see what the benefit is of switching it around like this. The author says the problems with the original implementation are: > The most obvious of whi

I don't see what the benefit is of switching it around like this. The author says the problems with the original implementation are: > The most obvious of which is that it has only one type that fulfills the interface with no obvious means of extension. (sic) Seems obvious to me. type Cat struct{} func (a Cat) Speaks() string { return "meow" } Does this not work? > Functions typically take concrete types instead of interface types. Ok...? This seems like some arbitrary rule that the creators of Go claimed was a good idea, I guess. The author has offered no justification for it. In general I guess I fail to see most of the proclaimed benefits of Go, every time I read articles like this I come away favoring something like Java for anything in the application layer. I can see preferring Go to C for low-level and systems programming, but I shudder to think of what a mess the large Go codebases must look like.

chewxy 9y ago
Author here. > Does this not work? It works However, this is what I have recently found quite a lot. An interface is defined: type Foo interface { Method1() unexportedMethod() } And in the same package, only one type (usually unexported) implements the interface. And the functions declared in the package typically take the concrete type instead of the interface type. This is typical when developers come from Java and they do `abstract class Fooer` and immediately do `class Foo implements Fooer` within the same package. This is an anti pattern in Go. > This seems like some arbitrary rule that the creators of Go claimed was a good idea, I guess No. I think I was unclear. I specifically mention that it's not a great idea. It's a code smell. Instead, interfaces should be defined at point-of-use.
- freyir 9y ago
  What's the point of exporting the Foo interface if other packages cannot create or use Foo values?
- keypusher 9y ago
  > I specifically mention that it's not a great idea. It's a code smell. Instead, interfaces should be defined at point-of-use. You still have not said WHY it's not a great idea, or what the benefits of defining the interfaces at point-of-use are.
  - chewxy 9y ago
    The benefits of defining interfaces at point of use is decoupling of dependencies. Imagine you have two packages: A and B. A defines interface Fooer and struct FooThing. Package B only requires anything that can call Foo(). But because the interface is defined at A, now B is forever tied to A. When you change something in A, you have to worry if it changes something in B as well. If instead the interface Fooer is defined in B, package A can change as much as it likes without B needing to change.

chewxy 9y ago

Author here. > Does this not work? It works However, this is what I have recently found quite a lot. An interface is defined: type Foo interface { Method1() unexportedMethod() } And in the same package, only one type (usually unexported) implements the interface. And the functions declared in the package typically take the concrete type instead of the interface type. This is typical when developers come from Java and they do `abstract class Fooer` and immediately do `class Foo implements Fooer` within the same package. This is an anti pattern in Go. > This seems like some arbitrary rule that the creators of Go claimed was a good idea, I guess No. I think I was unclear. I specifically mention that it's not a great idea. It's a code smell. Instead, interfaces should be defined at point-of-use.

freyir 9y ago
What's the point of exporting the Foo interface if other packages cannot create or use Foo values?
keypusher 9y ago
> I specifically mention that it's not a great idea. It's a code smell. Instead, interfaces should be defined at point-of-use. You still have not said WHY it's not a great idea, or what the benefits of defining the interfaces at point-of-use are.
- chewxy 9y ago
  The benefits of defining interfaces at point of use is decoupling of dependencies. Imagine you have two packages: A and B. A defines interface Fooer and struct FooThing. Package B only requires anything that can call Foo(). But because the interface is defined at A, now B is forever tied to A. When you change something in A, you have to worry if it changes something in B as well. If instead the interface Fooer is defined in B, package A can change as much as it likes without B needing to change.