|
|
|
|
|
|
by jayd16
2436 days ago
|
|
|
>How do you fail to implement the second method override on a single-method interface? Well in the example given, there is an interface Client with two methods. If a maintainer controls the Client interface and the HTTPClient implementation, the case can occur where that maintainer updates Client and HttpeClient. Suddenly, CachedHTTPClient in the downstream project has an unchached method and as far as my limited Go knowledge goes, no compiler error. >I'm talking about what happens in real Go code The case appears in the blog post. Would you say the blog is not idiomatic Go? |
|
|
Yes, it's a contrived example to make the point in the blog. Blog samples have to be taken that way. The vast majority of the time real code decorates in Go, it's with either A: an interface of 1 method or B: something sufficiently local in concern that this sort of thing isn't a concern, beyond it just being a bug (a compiler forcing you to specify an override won't save you from just sticking the minimal stub in). Part of why this can be a problem in Java is you tend to get a certain sprawl to your class hierarchy that doesn't occur in Go. Or most other languages, used well. Java's got some unique weaknesses in this area that do not generally translate.