|
|
|
|
|
by lolinder
700 days ago
|
|
I haven't done much Go, but TypeScript has similar characteristics with its interfaces and I haven't found refactoring to be much of an issue. If the interface changes then the type checker will alert you to all the places where you now have the wrong method type. The main difference between this and a Java-style explicit interface is that you have to make one jump from the error at the point of use to the definition of the class or record, where in Java the error points you right to the class. > And my main fear: how do I know I use the right object? I would tempted to add methods all the time to satisfy the target interface instead of using another object that already satisfies that interface. Why don't you do this with explicit interfaces? It's one extra line of code beyond the method implementation, and it's a backwards-compatible change. I suspect that the main reason you don't is because you know that class Foo shouldn't be a Bar, and the same logic can easily guide you with implicit interfaces. > Not knowing explicitly whether I can use an object or not is confusing, or am I missing something obvious? This one I'll agree with. Implicit interfaces work well in quick code that you're writing yourself that fits in your head. When you're trying to understand a library someone else wrote, though, being able to have the IDE list all the implementations of an interface is very valuable. Also, explicit interface tagging communicates authorial intent in a way that isn't possible with implicit interfaces. |
|