From c46981f24923d134ec48b678d5a7720d68c17c45 Mon Sep 17 00:00:00 2001 From: Geolffrey Mena Date: Sun, 28 Aug 2022 10:33:12 -0600 Subject: [PATCH] Adding a small contribution relation to my experience with interfaces --- CodeReviewComments.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/CodeReviewComments.md b/CodeReviewComments.md index a8a3628f..0cbe03f1 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. @@ -362,6 +362,7 @@ 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