golang inheritance to implement backbone like collection / model

I am looking into golang as my new goto language for my web-backend. My current language there is PHP, where I implemented a datastructure resembling the Backbone Collection/Model structure.

excursus Collection / Model

This means I have a Collection containing multiple Models. Models have an attributes dictionary for storing the actual "public data". Collections have multiple convenience methods operating on the array of Models (sort, getByIndex, getByMatchingParameter, etc). Models also have their share of convenience methods.

In daily life there will be 90% of "things" that are represented the same way. For example I can store an Address the same way I store my User. Having an AddressesCollection containing my Addresses I can simply ask my AddressesCollection to give me all AddressModels where city=Berlin. And implementing this matching in my base class I can do the logically same thing on my UserCollection giving me all my Users which are deactivated by deactivated=true.

But sometimes (10%) I need a special method. getGeoData for Addresses for example. Now, in my oop-world, I can simply create a new class extending my BaseModel adding my method and use my extended class everywhere where my base class was used.

My "i simply don't get it"

How does this work in Go. I read a lot introductions into embedding / composition. But simply do not get my head around this.

This is where I stand, keep in mind this is my playground for learning the "inheritance" concept, not for having a production ready Collection / Model implementation.

GoPlayground

What I get is that I haven't "understood" how to write a "generic" method accepting not-quite-inherited types. I have the feeling that I have to use an interface there somewhere to get this "inheritance"/"extended class" feeling. But my current use of this is... well...

But maybe I am completely wrong in my concept of implementing my desired structure that way in go at all? Maybe there is a much more elegant way. Any hints greatly appreciated!

You are pretty close to getting it right, but you have mixed up multiple different things.

Complete example: https://play.golang.org/p/wpj82QRVUP

1. Type embedding

So you have two models User, Address and they both share common fields and maybe methods. This is a good reason to create a common struct for both: Model, as shown in the link above. All three structs are of different types.

2. Collections

You can have a collection of interfaces or collection of defined types. So when to use which?

If you have a collection of addresses, defined the type of follows:
type AddrCollection []*Address. And then implement whatever method you want on AddrCollection type.

If you have a collection of models, similarly define type ModelCollection []*Model, but then passing Address to the ModelCollection would require to "extract" the embedded type.

If you have a collection of something, then define a collection of interfaces (DescriberCollection in the example), but then you would not have GetByAddress() defined on it, and it would only exist in AddrCollection

3. Interfaces

They have no fields they only define method signatures to be implemented. In Go interfaces are normally accepted and never returned, that gives u a benefit to have clean and goal-oriented design. Interfaces is a way to allow other users (or other packages) to use your packages/libraries in a way that they do not need to implement your types, but rather a certain methods. They can reuse your defined types, or they can plug-in their own implementations of the interface. So what is an interface, it is a way of saying: here are the set of method signatures, as long as you implement them you can use my package

Ok, looks like I really didn't understand the go-way of doing this.

The buzzwords that helped me to move on:

• ORM
• go generate

Projects that look like solving my issue:

• GORM
• SQLBoiler

Thanks for the answers, anyway!