From c7f4b46df55feb4e9afdec1e19b20030b1cee4bf Mon Sep 17 00:00:00 2001 From: Ian Lance Taylor Date: Sun, 28 Aug 2022 19:43:15 -0700 Subject: [PATCH] Revert 0b3ed88ffda30443d4e84f6e8e4b399c079c28a1...c46981f24923d134ec48b678d5a7720d68c17c45 on CodeReviewComments --- CodeReviewComments.md | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/CodeReviewComments.md b/CodeReviewComments.md index 0cbe03f1..58a11756 100644 --- a/CodeReviewComments.md +++ b/CodeReviewComments.md @@ -352,7 +352,7 @@ implementing package should return concrete (usually pointer or struct) types: that way, new methods can be added to implementations without requiring extensive refactoring. -Do not define interfaces on the `implementor` side of an API "for mocking"; +Do not define interfaces on the implementor side of an API "for mocking"; instead, design the API so that it can be tested using the public API of the real implementation. @@ -360,10 +360,6 @@ Do not define interfaces before they are used: without a realistic example of usage, it is too difficult to see whether an interface is even necessary, let alone what methods it ought to contain. -If you need to inject a dependency into private methods consider not using interfaces as there is no ambiguity in the methods over which you have control of what is received, don't add unnecessary abstractions. The exception is the case where an abstraction is actually required to "group objects into their common behaviors". - -Avoid returning interfaces as this would cause an "indirection" problem by limiting access to public attributes in the structure. Use this approach in specific cases such as strict encapsulation. - ``` go package consumer // consumer.go