ChangeRaid() or whatever. So this sounds like what Paul was suggesting but
how do the extra interfaces help? Could you guys point out some usages in
the standard lib maybe (or stdlib tests) which use interfaces embedded in
structs?
On Thursday, April 16, 2015 at 10:41:31 PM UTC-7, Egon wrote:
etc. It seems that the real world context is necessary to properly analyze
this situation.
It seems that somehow and something should be split differently. e.g.
"Machine" shouldn't be an interface, but
type Machine struct {
CPU
Memory
Disk
}
Where the CPU/Memory/Disk are interfaces. (I'm just making things up at
the moment).
+ Egon
--On Friday, 17 April 2015 04:16:07 UTC+3, jonathan...@gmail.com wrote:
Hello gophers!
I am trying to find what is idiomatic or even a good way to structure a
large "context". So this application has an interface Machine that has its
implementation switched out on different machines. Problem I have is with
testing. If I just want to stub out a single method of that interface I
have to create a stub struct with a bunch of empty functions, it becomes
unwieldy in tests. I have heard of three approaches, mock lib, split the
interface, and have a struct with function values.
Mock lib approach I would rather avoid.
Splitting the interface has the issue that now I have to pass around all
the split interfaces which are roughly equal in number to the functions in
Machine.
Struct with function values is odd because I am still passing this whole
thing around whereas a portion of the application or my tests really only
need the one function. Perhaps small and not measured but I imagine it is
slower because of the extra indirection.
My intuition tells me I should be able to do it with better interface
design but I'm coming up with nothing :(
Can you share what that Machine actually is and what are the interfacesHello gophers!
I am trying to find what is idiomatic or even a good way to structure a
large "context". So this application has an interface Machine that has its
implementation switched out on different machines. Problem I have is with
testing. If I just want to stub out a single method of that interface I
have to create a stub struct with a bunch of empty functions, it becomes
unwieldy in tests. I have heard of three approaches, mock lib, split the
interface, and have a struct with function values.
Mock lib approach I would rather avoid.
Splitting the interface has the issue that now I have to pass around all
the split interfaces which are roughly equal in number to the functions in
Machine.
Struct with function values is odd because I am still passing this whole
thing around whereas a portion of the application or my tests really only
need the one function. Perhaps small and not measured but I imagine it is
slower because of the extra indirection.
My intuition tells me I should be able to do it with better interface
design but I'm coming up with nothing :(
etc. It seems that the real world context is necessary to properly analyze
this situation.
It seems that somehow and something should be split differently. e.g.
"Machine" shouldn't be an interface, but
type Machine struct {
CPU
Memory
Disk
}
Where the CPU/Memory/Disk are interfaces. (I'm just making things up at
the moment).
+ Egon
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
