this question is related to Passing struct with anonymous field in Go but different in that I am dealing with a function that handles an array of Parent items rather than just one struct, ie:
package main
import "fmt"
type Parent struct {
Dad string
}
type Child struct {
Parent
Son string
}
func myfunc(data []Parent) {
for n, _ := range data {
fmt.Printf("Dad is %s\n", data[n].Dad)
}
}
func main() {
data := make([]Child, 2)
data[0].Dad = "pappy"
data[0].Son = "sonny"
data[1].Dad = "daddy"
data[1].Son = "billy"
myfunc(data)
}
I tried to cast data to an array of Parents like myfunc([]Parent(data)) but that didnt work and obviously the solution of myfunc(data.Parent) wont work on an array.
Is there a reasonable solution to this in golang without resorting to creating a new slice or generics which are not out of beta yet?
Cheers
You cannot do this even with generics. data[n].Dad will not work.
The reasonable way to deal with it is to use an interface, but still, you have to create an interface slice for it:
type WithDad interface {
GetDad() string
}
func (p Parent) GetDad() string {return p.Dad}
func myFunc(data []WithDad) {
...
}
...
arr:=make([]WithDad,0,len(data))
for _,x:=range data {
arr=append(arr,x)
}
myFunc(arr)
The reason for this is how the type system works and how slices are passed around. The slice []Child points to an array where each entry is a Child. A function that takes []Parent expects a slice whose elements are Parent, which is a different type, so you cannot pass one for the other.
The slice []WithDad points to an array where each entry is an interface. Each such entry points to the Child or Parent entry in another slice.
Just for completeness I made a complete version of Burak Serdar code I got working (I like it when full working examples are posted for me to cut and paste later :P) ... note I deliberately return a pointer to the Parent because in practice its likely you will want to work on that complete struct and not just read 1 field.
package main
import "fmt"
type WithDad interface {
GetDad() *Parent
}
type Parent struct {
Dad string
}
func (p *Parent) GetDad() *Parent {
return p
}
type Child struct {
Parent
Son string
}
func (c *Child) GetDad() *Parent {
return &c.Parent
}
func myfunc(data []WithDad) {
for n, _ := range data {
fmt.Printf("Dad is %s\n", data[n].GetDad().Dad)
}
}
func main() {
data := make([]WithDad, 2)
data[0] = &Child{Parent: Parent{Dad: "pappy"}, Son: "sonny"}
data[1] = &Child{Parent: Parent{Dad: "daddy"}, Son: "billy"}
myfunc(data)
}
Your structure with Child being a composite of Parent and a string (which I guess contains the name) makes little sense. A child is not a parent plus their name. In fact you only have one concept, namely Person, who potentially has a parent. Please consider the following approach:
package main
import "fmt"
type Person struct {
Name string
Parent *Person
}
func myfunc(data []Person) {
for n, _ := range data {
fmt.PrintLn("My name is", n.Name)
if n.Parent != nil {
fmt.PrintLn("My dad is", n.Parent.Name)
}
}
}
func main() {
data := make([]Person, 2)
data[0].Name = "daddy"
data[1].Name = "billy"
data[1].Parent = &data[0]
myfunc(data)
}
Related
I'm OOP guy, recently I have to work on Golang the language that I haven't done it before. Though I already went through many articles talking about composition, I notice it's a bit tricky to use it properly on Golang
Let's say I have two examples of Golang composition, I don't know which one will be correct, and would it be different between of them? Thank you
First example
type BaseClass struct {
db *DB
}
func NewBaseClass(db *DB) *BaseClass {
return &BaseClass{db}
}
type ChildrenClass1 struct {
baseClass *BaseClass
}
func NewChildrenClass1(db *DB) *ChildrenClass1 {
baseClass := NewBaseClass(db)
return &ChildrenClass1{baseClass}
}
type ChildrenClass2 struct {
baseClass *BaseClass
}
func NewChildrenClass2(db *DB) *ChildrenClass2 {
baseClass := NewBaseClass(db)
return &ChildrenClass2{baseClass}
}
func main(){
db := NewDB()
chilrend1 := NewChildrenClass1(db)
chilrend2 := NewChildrenClass2(db)
}
Second example
type BaseClass struct {
db *DB
}
func NewBaseClass(db *DB) *BaseClass {
return &BaseClass{db}
}
type ChildrenClass1 struct {
baseClass *BaseClass
}
func NewChildrenClass1(baseClass *BaseClass) *ChildrenClass1 {
return &ChildrenClass1{baseClass}
}
type ChildrenClass2 struct {
baseClass *BaseClass
}
func NewChildrenClass2(baseClass *BaseClass) *ChildrenClass2 {
return &ChildrenClass2{baseClass}
}
func main(){
db := NewDB()
baseClass := NewBaseClass(db)
chilrend1 := NewChildrenClass1(baseClass)
chilrend2 := NewChildrenClass2(baseClass)
}
In Go you probably will not find a proper way to define composition or aggregation as you may find in many other languages that are OOP based. This is just because Go has no classes, no objects, no exceptions, and no templates.
But Go has structs. Structs are user-defined types. Struct types (with methods) serve similar purposes to classes in other languages.
Said that, let's see some common definitions and see what we can do:
Composition implies a relationship where the child cannot exist independent of the parent. Example: House (parent) and Room (child). Rooms don't exist separate to a House[1].
Aggregation, in other hand, implies a relationship where the child can exist independently of the parent. Example: Classroom (parent) and Student (child). Delete the Classroom and the Students still exist[1].
So, in aggregation and composition the "instance" "owns" an object of another type. But there is a subtle difference: Aggregation implies a relationship where the child can exist independently of the parent. Composition implies a relationship where the child cannot exist independent of the parent.
So far, that's what we know now from composition:
The child cannot exist without the parent
Composition refers to combining simpler types to make more complex ones
And of course, we mainly use it to be able to reuse code
Answer to your question:
Both looks correct but,
The first example is closer to a composition, because the child will not exist without the parent;
The second example is more like an aggregation, because if you remove the parent, the child will keep existing.
I re-wrote your code on an attempt to exemplify it:
First example re-written
package main
//Lamp struct is here to suppress the *DB that was in the original example
type Lamp struct {}
type Room struct {
Lamps *[]Lamp
}
func NewRoom(l *[]Lamp) *Room {
return &Room{l}
}
type House1 struct {
Room *Room
}
func NewHouse1(l *[]Lamp) *House1 {
r := NewRoom(l)
return &House1{r}
}
type House2 struct {
Room *Room
}
func NewHouse2(l *[]Lamp) *House2 {
r := NewRoom(l)
return &House2{r}
}
func main(){
lamps := []Lamp{}
house1 := NewHouse1(&lamps)
house2 := NewHouse2(&lamps)
}
Second example re-written:
package main
type LibraryCard struct {}
type Student struct {
LibCard *LibraryCard
}
func NewStudent(l *LibraryCard) *Student {
return &Student{l}
}
type Classroom1 struct {
Student *Student
}
func NewClassroom1(s *Student) *Classroom1 {
return &Classroom1{s}
}
type Classroom2 struct {
Student *Student
}
func NewClassroom2(s *Student) *Classroom2 {
return &Classroom2{s}
}
func main(){
lc := new(LibraryCard)
student := NewStudent(lc)
classroom1 := NewClassroom1(student)
classroom2 := NewClassroom2(student)
}
I am new to go (golang). That is why my question may be irrelevant (or impossible to answer).
I have created two structs. Both of these embed another struct. Now I want to update a field of the embedded struct inside a function.
package main
import (
"fmt"
"reflect"
"time"
)
type Model struct {
UpdatedAt time.Time
}
type Fruit struct {
Model
label string
}
type Animal struct {
Model
label string
}
func update(v interface{}) {
reflectType := reflect.TypeOf(v)
reflectKind := reflectType.Kind()
if reflectKind == reflect.Ptr {
reflectType = reflectType.Elem()
}
m := reflect.Zero(reflectType)
fmt.Println(m)
}
func main() {
apple := &Fruit{
label: "Apple",
}
tiger := &Animal{
label: "Tiger",
}
update(apple)
update(tiger)
fmt.Println(apple)
fmt.Println(tiger)
}
I wish to implement the update function so that it will put the current time in UpdatedAt of the passed struct. But I am not able to do this.
In this case, the field of Fruit and Animal is same: label. But it will not always be. Please keep that in mind when providing your suggestions.
Any guidance would be much appreciated.
I'd avoid reflect or interface{} if you're starting to learn go. Beginners usually fall back on them like a void * crutch. Try to use concrete types or well defined interfaces.
This should get you going:
type Timestamper interface {
Update()
UpdatedTime() time.Time
}
type Model struct {
updated time.Time
}
func (m *Model) Update() { m.updated = time.Now() }
func (m *Model) UpdatedTime() time.Time { return m.updated }
type Fruit struct {
Model
label string
}
type Animal struct {
Model
label string
}
// update will work with a `Model` `Animal` or `Fruit`
// as they all implement the `Timestamper` interface`
func update(v Timestamper) {
v.Update()
}
Playground: https://play.golang.org/p/27yDVLr-zqd
Assuming you want to achieve this via reflection: first of all, you have to pass a pointer to the struct. You're now passing a copy of the struct, so any modifications done in update will be done on the copy, not on the instance you passed in. Then, you can lookup the field UpdatedAt in the interface passed in, and set it.
That said, that's probably not the best way to do this. Another way of doing this without reflection is:
func update(in *Model) {
in.UpdatedAt = time.Now()
}
func main() {
apple := &Fruit{}
update(&apple.Model)
}
Or:
func (in *Model) update() {
in.UpdatedAt = time.Now()
}
func main() {
apple := &Fruit{}
apple.update()
}
Below I have an example of one structure which embeds another. I'm trying to figure out how to pass the more specific structure pointer to be stored in a less specific one. You can think of it as a collection. Wrapping in an interface doesn't seem to work, as doing so would make a copy, which isn't valid for structs with locks. Ideas?
package stackoverflow
import "sync"
type CoolerThingWithLock struct {
fancyStuff string
ThingWithLock
}
func NewCoolerThingWithLock() *CoolerThingWithLock {
coolerThingWithLock := &CoolerThingWithLock{}
coolerThingWithLock.InitThingWithLock()
return coolerThingWithLock
}
type ThingWithLock struct {
value int
lock sync.Mutex
children []*ThingWithLock
}
func (thingWithLock *ThingWithLock) InitThingWithLock() {
thingWithLock.children = make([]*ThingWithLock, 0)
}
func NewThingWithLock() *ThingWithLock {
newThingWithLock := &ThingWithLock{}
newThingWithLock.InitThingWithLock()
return newThingWithLock
}
func (thingWithLock *ThingWithLock) AddChild(newChild *ThingWithLock) {
thingWithLock.children = append(thingWithLock.children, newChild)
}
func (thingWithLock *ThingWithLock) SetValue(newValue int) {
thingWithLock.lock.Lock()
defer thingWithLock.lock.Unlock()
thingWithLock.value = newValue
for _, child := range thingWithLock.children {
child.SetValue(newValue)
}
}
func main() {
thingOne := NewThingWithLock()
thingTwo := NewCoolerThingWithLock()
thingOne.AddChild(thingTwo)
thingOne.SetValue(42)
}
Error: cannot use thingTwo (type *CoolerThingWithLock) as type
*ThingWithLock in argument to thingOne.AddChild
It's impossible to store the wrapping type in []*ThignWithLock since go has no notion of structural subtyping.
Your assertion that an interface will result in copying is incorrect, and you can get the desired effect by doing:
type InterfaceOfThingThatParticipatesInAHierarchy interface {
AddChild(InterfaceOfThingThatParticipatesInAHierarchy)
SetValue(int)
}
type ThingWithLock struct {
...
children []InterfaceOfThingThatParticipatesInAHierarchy
}
func (thingWithLock *ThingWithLock) AddChild(newChild InterfaceOfThingThatParticipatesInAHierarchy) { ... }
As long as the interface is implemented on a *ThingWithLock and not ThingWithLock, there will be no copying of the receiver struct itself, only the pointer to the struct will be copied on the stack.
I have two types, B and C, which share all methods, but implement one of them differently. I would like to express this by having a parent type A, containing the implementations of the shared methods, and embedding A in B and C. (Don't Repeat Yourself!) The snag is that the method that differs between B and C is called in many of the shared methods. What's the idiomatic way to structure such code?
My current implementation looks essentially like this (https://play.golang.org/p/RAvH_hBFDN; based on an example by Dave Cheney):
package main
import (
"fmt"
)
type Legger interface {
Legs() int
}
type Cat struct {
Name string
L Legger
}
// Cat has many methods like this, involving calling c.L.Legs()
func (c Cat) PrintLegs() {
fmt.Printf("I have %d legs.\n", c.L.Legs())
}
// OctoCat is a Cat with a particular implementation of Legs
type OctoCat struct {
Cat
}
func (c OctoCat) Legs() int {
return 8
}
// TetraCat has a different implementation of Legs
type TetraCat struct {
Cat
}
func (c TetraCat) Legs() int {
return 4
}
func main() {
c := TetraCat{Cat{"Steve",nil}}
c.L = &c
c.PrintLegs() // want 4
o := OctoCat{Cat{"Bob",nil}}
o.L = &o
o.PrintLegs() // want 8
}
The type definitions themselves look nice and clean, but the initialization code in main is wacky (first the nil in the struct literal, then c.L = &c, what?). Is there a better solution?
A similar pattern was presented in is it possible to call overridden method from parent struct in golang?, but the question of whether this is the idiomatic way to proceed was not answered.
Two approaches I would consider for solving this:
1. Refactor your code to have a single type Cat with the fields Name string and Legs int:
package main
import (
"fmt"
)
type Cat struct {
Name string
Legs int
}
func (c *Cat) PrintLegs() {
fmt.Printf("I have %d legs.\n", c.Legs)
}
func main() {
c := &Cat{"Steve", 4}
c.PrintLegs() // want 4
o := &Cat{"Bob", 8}
o.PrintLegs() // want 8
}
https://play.golang.org/p/_PNAu3sgG8
2. Do away with the Cat type and just have TetraCat and OctoCat implement the Legger interface:
package main
import (
"fmt"
)
type Legger interface {
Legs() int
}
func PrintLegs(l Legger) {
fmt.Printf("I have %d legs.\n", l.Legs())
}
// OctoCat is a Cat with a particular implementation of Legs
type OctoCat struct {
Name string
}
func (c *OctoCat) Legs() int {
return 8
}
// TetraCat has a different implementation of Legs
type TetraCat struct {
Name string
}
func (c *TetraCat) Legs() int {
return 4
}
func main() {
c := &TetraCat{"Steve"}
PrintLegs(c) // want 4
o := &OctoCat{"Bob"}
PrintLegs(o) // want 8
}
https://play.golang.org/p/m4QvKhSj0w
I want to add a convenience util method on to gorilla/mux Route and Router types:
package util
import(
"net/http"
"github.com/0xor1/gorillaseed/src/server/lib/mux"
)
func (r *mux.Route) Subroute(tpl string, h http.Handler) *mux.Route{
return r.PathPrefix("/" + tpl).Subrouter().PathPrefix("/").Handler(h)
}
func (r *mux.Router) Subroute(tpl string, h http.Handler) *mux.Route{
return r.PathPrefix("/" + tpl).Subrouter().PathPrefix("/").Handler(h)
}
but the compiler informs me
Cannot define new methods on non-local type mux.Router
So how would I achieve this? Do I create a new struct type that has an anonymous mux.Route and mux.Router fields? Or something else?
As the compiler mentions, you can't extend existing types in another package. You can define your own alias or sub-package as follows:
type MyRouter mux.Router
func (m *MyRouter) F() { ... }
or by embedding the original router:
type MyRouter struct {
*mux.Router
}
func (m *MyRouter) F() { ... }
...
r := &MyRouter{router}
r.F()
I wanted to expand on the answer given by #jimt here. That answer is correct and helped me tremendously in sorting this out. However, there are some caveats to both methods (alias, embed) with which I had trouble.
note: I use the terms parent and child, though I'm not sure that is the best for composition. Basically, parent is the type which you want to modify locally. Child is the new type that attempts to implement that modification.
Method 1 - Type Definition
type child parent
// or
type MyThing imported.Thing
Provides access to the fields.
Does not provide access to the methods.
Method 2 - Embedding (official documentation)
type child struct {
parent
}
// or with import and pointer
type MyThing struct {
*imported.Thing
}
Provides access to the fields.
Provides access to the methods.
Requires consideration for initialization.
Summary
Using the composition method the embedded parent will not initialize if it is a pointer. The parent must be initialized separately.
If the embedded parent is a pointer and is not initialized when the child is initialized, a nil pointer dereference error will occur.
Both type definition and embed cases provide access to the fields of the parent.
The type definition does not allow access to the parent's methods, but embedding the parent does.
You can see this in the following code.
working example on the playground
package main
import (
"fmt"
)
type parent struct {
attr string
}
type childAlias parent
type childObjParent struct {
parent
}
type childPointerParent struct {
*parent
}
func (p *parent) parentDo(s string) { fmt.Println(s) }
func (c *childAlias) childAliasDo(s string) { fmt.Println(s) }
func (c *childObjParent) childObjParentDo(s string) { fmt.Println(s) }
func (c *childPointerParent) childPointerParentDo(s string) { fmt.Println(s) }
func main() {
p := &parent{"pAttr"}
c1 := &childAlias{"cAliasAttr"}
c2 := &childObjParent{}
// When the parent is a pointer it must be initialized.
// Otherwise, we get a nil pointer error when trying to set the attr.
c3 := &childPointerParent{}
c4 := &childPointerParent{&parent{}}
c2.attr = "cObjParentAttr"
// c3.attr = "cPointerParentAttr" // NOGO nil pointer dereference
c4.attr = "cPointerParentAttr"
// CAN do because we inherit parent's fields
fmt.Println(p.attr)
fmt.Println(c1.attr)
fmt.Println(c2.attr)
fmt.Println(c4.attr)
p.parentDo("called parentDo on parent")
c1.childAliasDo("called childAliasDo on ChildAlias")
c2.childObjParentDo("called childObjParentDo on ChildObjParent")
c3.childPointerParentDo("called childPointerParentDo on ChildPointerParent")
c4.childPointerParentDo("called childPointerParentDo on ChildPointerParent")
// CANNOT do because we don't inherit parent's methods
// c1.parentDo("called parentDo on childAlias") // NOGO c1.parentDo undefined
// CAN do because we inherit the parent's methods
c2.parentDo("called parentDo on childObjParent")
c3.parentDo("called parentDo on childPointerParent")
c4.parentDo("called parentDo on childPointerParent")
}
Expanding on one of the other answers, in my case the parent is an array. If you
want to add methods, but also have access to the parent methods, you must wrap
when defining the type, and wrap when declaring a variable:
package main
type parent []int
func (p parent) first() int {
return p[0]
}
type child struct {
parent
}
func (c child) second() int {
return c.parent[1]
}
func main() {
a := child{
parent{1, 2},
}
first := a.first()
second := a.second()
println(first == 1, second == 2)
}