Sometimes you don’t know what the implementation will be yet, and writing a bunch of interfaces out can help you discover what it should be, then you start working it out with interfaces gradually giving way to implementation.
Interfaces are rarely rarely about interoperability even in Java. Most interfaces have one implementation. Instead, they are about abstraction, design, and so on. This article assumes that the end product is what was intended all along.
This. So many packages are a pain to test, because only a concrete implementation is provided. If an interface was used, consumers can swap it out for a mock implementation. It is an almost endemic problem, but the article is criticizing the only available solution (apart from forking).
I am utterly sick of writing fragile scaffolding to deal with these dependencies, to the point I wish that Go provided an implicit interface for every declared type. Testing would be so much easier if I could pass in a MockFoo instead of a Foo, provided MockFoo satisfied the implicit interface.
The article, from how I read it, is not suggesting single-implementation interfaces are the problem but instead where those interfaces are stored. The package accepting the interface should define the interface it needs (and perhaps that package defines the mock implementation), and the implementation should exist somewhere else.
I've programmed in both ways and they each have there place. But in general this is the right way, you shouldn't export interfaces, you should export concrete types and then use the documentation and tests to example what types of interfaces the types can cover.
TypeScript, having a purely structural type system, means any class has an interface. Unfortunately, if the class has any private or protected members, its interface becomes unimplementable.
> Most interfaces have one implementation. Instead, they are about abstraction, design, and so on.
Then what you want is an abstract data type. Unlike interfaces, which can be implemented anywhere, an abstract data type is implemented in a single place. This has obvious benefits for performance (clients don't need to dynamically dispatch on operations), control (implementors don't need to worry about malicious clients supplying impostors) and precision (a single module can export several abstract types, whose implementations are mutually dependent).
Go's interfaces are pretty terrible at all of the above. Not that Java provides anything substantially better.
I have only seen abstract data types used to describe stacks and queues, and never in the context of a larger design where the underlying implementations weren’t data structures but objects. Do you have any good examples?
If you want data abstraction to do at least a minimum of static invariant enforcement, you pretty much have to use abstract data types. But if you're fine with littering logs with “exception was caught here, such and such data structure was corrupted”, suit yourself.
It isn’t that. Abstract data types are designed specifically for data structures like queues and stacks, they don’t make much sense for objects that don’t have such well defined invariants. No major language has adopted them for that reason.
A Go interface type is not an abstract data type. The difference is not even subtle:
(0) An ADT has a single internal representation that is known to the implementor, but hidden from users. The upside is that the ADT implementor can use his knowledge of the representation to optimize on n-ary operations, i.e., operations that act on several instances of the ADT. The downside is that ADTs cannot be extended by third parties. You would have to create a different ADT, even if satisfies the same contract.
(1) A Go interface has a list of methods, but does not proscribe any fixed internal representation. The upside is that anyone can create values of an interface type as long as they can implement the methods. The downside is that it is difficult to implement n-ary operations, because, at any point in the program, the implementor only knows the internal representation of the single value they are currently creating.
In other words, ADTs optimize for efficiency and predictability, whereas interfaces optimize for flexibility and extensibility. As a general rule, ADTs require more time than interfaces to plan ahead their design and implementation, but already implemented ADTs are easier to use correctly than already implemented interfaces.
I haven't dealt with Java in the last ... 12 years (and only very little back then), but I liked the convention of naming Interfaces after adjectives. In Java, it would be named Sortable, and element types of a sortable collection would implement Comparable<T>.
Interfaces are rarely rarely about interoperability even in Java. Most interfaces have one implementation. Instead, they are about abstraction, design, and so on. This article assumes that the end product is what was intended all along.