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
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
discre
I'm not aware of a Go convention for this purpose.
If the struct is private to the package you can use a plain "customer". If
not you can use something like "BasicCustomer", "SimpleCustomer" or
"GenericCustomer". I rather leave the interface name as "Customer" instead
of using something like "ICus
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
// (unex
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
Henry,
the case that I'm describing is when you're not exporting any and you're
using your interface for mocking purposes. The interface cannot be called
MockedCustomer, because it's used in the main code...there will be a
mockCustomer struct in the test that implements the interface. The quest
If you are exporting your interface but hiding your implementation, I usually
name my interface Customer and my struct customerImpl. If you are using your
interface for mocking purposes only, I would name it MockedCustomer. If you're
exporting both the interface and its implementations, I would
If you are exporting your interface but hiding your implementation, I usually
name my interface Customer and my struct customerImpl. If you are using your
interface for mocking purposes only, I would name it MockedCustomer. If you're
exporting both the interface and its implementations, I would
Lars,
100% agree with your rationale; my question is an edge case of it.
The only need for these interfaces is for mocking the struct on tests (as
shown in the link on my original post). Therefore, there is no other
implementation of the interface.
Your suggestion is close to our discussed opti
On Sat, Mar 04, 2017 at 03:57:48PM -0800, mlg wrote:
> according to your rationale, I believe the case I'm referring to is when
> the interface represents a domain object (e.g. Consumer). In such case, if
> you don't plan on exporting your interface (therefore naming it
> `consumer`), how would
Henry,
according to your rationale, I believe the case I'm referring to is when
the interface represents a domain object (e.g. Consumer). In such case, if
you don't plan on exporting your interface (therefore naming it
`consumer`), how would you name the implementing struct and why? If
possibl
11 matches
Mail list logo
