I have structs with duplicate fields and duplicate code to go along with them. The problem is that the duplicate code does make use of non-common fields. Here is an example of the code.
https://play.golang.org/p/IkoNJTdoVLD I could extract the duplicate code sections into a method, eliminating the duplication. The problem is that not all of the fields are the same. If I had two separate function to deal with the non-common field usage and I could pass the respective helper into the extracted function (with the common-code) for it to invoke when it's time for the non-common code to execute, then that would be ideal. Is there some way to do this? On Wednesday, September 12, 2012 at 2:04:27 AM UTC-7 rog wrote: > It's worth setting aside an hour and having a good > read of the relevant sections of the Go specification. > It's one of the more complex bits of the spec, but it's > still not hard and you'll get a much better idea of the > things you can do with embedding. > > http://golang.org/ref/spec#Selectors > http://golang.org/ref/spec#Struct_types > > > On 12 September 2012 03:01, beatgammit <beatg...@gmail.com> wrote: > > Huh, I didn't know that embedding could be done for types to bring their > > implementations along. > > > > Could I do something like this then: > > > > type DBModule struct {} > > func (DBModule) Settings() map[string]string > > func (DBModule) Set(string, string) > > > > type ModA struct { > > *DBModule > > } > > func (a *ModA) Id() string {return "ModA"} > > func (a *ModA) Format(r io.Reader) io.Reader { return r } > > > > Would that still implement the Module interface (i.e. pull in DBModule's > > methods)? If so, that would save on the code reuse problem that I'm > having. > > My modules are pretty easy to categorize into types (some use the DB and > > some don't), so this means I can get rid of my hacky way of doing > things... > > > > BTW, it's more like 100+ lines of duplication without my hack, so it is > > substantial. > > > > Thanks!! > > > > On Tuesday, September 11, 2012 7:48:28 PM UTC-6, Jesse McNelis wrote: > >> > >> On Wed, Sep 12, 2012 at 11:21 AM, beatgammit <beatg...@gmail.com> > wrote: > >> > I've thought about how to re-architect it to avoid the problem, but > >> > I haven't been able to come up with anything that doesn't require a > lot > >> > of > >> > code duplication or global functions. > >> > >> When people say "a lot of code duplication" they often mean a few lines. > >> Go doesn't have global functions, it just has package level functions. > >> > >> Functions are one of the major ways to reuse code in Go. You define > >> some types that satisfy > >> some interface and then you write functions that act on that interface. > >> > >> If you have some similar fields in structs that you need to access, > >> embedding > >> (http://golang.org/doc/effective_go.html#embedding) can be helpful in > >> reducing duplication > >> of Get/Set style methods. > >> > >> I'm still not sure what you're trying to do, but your format() method > >> seems like it would be better if your type was an io.Reader and > >> format() was instead a function that took an io.Reader and returned > >> your type. > >> > >> > >> > >> > >> > >> -- > >> ===================== > >> http://jessta.id.au > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/caadc8cd-fb05-4b71-9a4c-ab7a649eaa84n%40googlegroups.com.
