Henry,
thank you; your first paragraph was the answer I was looking for. Sorry for
explaining so poorly. If I understand you correctly, you don't feel super
strongly about it but you reckon you'd suffix "Impl" to the struct as a
general rule. You'd leave it to the programmers discretion, though.
If possible, I'd appreciate if someone else would share a different opinion.
On Monday, 6 March 2017 04:35:13 UTC+13, Henry wrote:
>
> I would name your interface 'customer', the struct in the main code
> 'customerImpl' and the struct in the test code 'mockedCustomer'. However,
> we are dealing with unexported types here. I tend to be less picky about
> names for unexported types and prefer to leave them to each programmer's
> discretion as long as the names are reasonable.
>
> In general, I adopt the following guidelines:
>
> For an exported interface that does not represent any domain idea and they
> are there because of their methods, I would adopt the "-er" naming
> convention. (eg. Stringer, Closer, etc.)
> For an exported interface that represents a domain idea, I would use the
> domain object name. It is preferable to have a noun with no adjective (eg.
> Customer, Product, Shop, etc.)
>
> For a struct that is not exported but it is the concrete implementation
> of an exported interface, I would use the "<interface_name>+Impl"
> or "<adjective><interface_name>+Impl" to indicate that the struct is the
> concrete implementation of a public interface (eg. customerImpl,
> specialCustomerImpl, customShopImpl, etc.) .
>
> For a struct that is exported, I would use the "<adjective><noun>" format.
> (eg. PublicAccountant, etc.).
>
> For any interface or struct that is used for testing purposes only, I
> would prefix the name with the word "mocked".
>
> For any interface or struct that is not exported, I would leave them to
> the programmer's discretion.
>
> That's what I would do. You may adopt a different naming convention.
> As far as I know, Go puts very little restriction on the subject.
>
> On Sunday, March 5, 2017 at 10:04:47 AM UTC+7, mlg wrote:
>
>> Nope, that's not it :'(. Here's a better way to explain:
>>
>> main.go
>> // (unexported)
>> type database?? interface { // how do I name this?
>> query() (result, error)
>> }
>>
>> // (unexported)
>> type database?? struct {} // how do I name this?
>>
>> func (d database??) query() (result, error) {
>> ...
>> }
>>
>> test.go
>> // (unexported)
>> type mockDatabase struct {} // this name makes sense to me
>>
>> func (d database??) query() (result, error) {
>> ...
>> }
>>
>> If I've known it was gonna be this hard to get my point across, I would
>> have done this from the start; I'm terribly sorry for wasting so much of
>> your time.
>>
>> On Sunday, 5 March 2017 15:30:17 UTC+13, Henry wrote:
>>>
>>> Let's see if I understand your question correctly. You have the
>>> interface in your main code, and the implementing struct in your test code.
>>> Do I get that right?
>>>
>>> Another question is whether the main code and the test code live in the
>>> same package or different package. I normally put my test code in a
>>> separate package. So if my main code is in package abc, then my test code
>>> would be in abc_test.
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
