is it possible to call overridden method from parent struct in Golang?

后端 未结 6 1507
攒了一身酷
攒了一身酷 2020-11-27 04:34

I want to implement such code, where B inherit from A and only override A\'s Foo() method, and I hope the code to print B.Foo(), but it still print A.Foo(), it seems that th

相关标签:
6条回答
  • 2020-11-27 05:05

    As you wrote, what Go has is not really inheritance, the method that allows inheritance like features is called Embedding.

    http://golang.org/doc/effective_go.html#embedding

    What it means basically is that the embedded struct has no idea that it is embedded, so you cannot override anything that is called from it. You can actually take the embedded struct and take a reference for it only from the embedding struct.

    So your best way to do it is more or less like your second example - through some sort of dependency injection using interfaces. i.e - A has a reference to some interface that does the actual work, say worker, that writes to a file or whatever. Then when instantiating B, you also replace A's worker with another worker (you can do it even without embedding A of course). The A just does something like myWorker.Work() without caring what worker it is.

    0 讨论(0)
  • 2020-11-27 05:05

    Recently I have a need to do this and the composition method proposed by OP works great.

    I try to create another example to try to demonstrate the parent and child relationship and make it easier to read.

    https://play.golang.org/p/9EmWhpyjHf:

    package main
    
    import (
        "fmt"
        "log"
    )
    
    type FruitType interface {
        Wash() FruitType
        Eat() string
    }
    
    type Fruit struct {
        name  string
        dirty bool
        fruit FruitType
    }
    
    func (f *Fruit) Wash() FruitType {
        f.dirty = false
        if f.fruit != nil {
            return f.fruit
        }
        return f
    }
    func (f *Fruit) Eat() string {
        if f.dirty {
            return fmt.Sprintf("The %s is dirty, wash it first!", f.name)
        }
        return fmt.Sprintf("%s is so delicious!", f.name)
    }
    
    type Orange struct {
        *Fruit
    }
    
    func NewOrange() *Orange {
        ft := &Orange{&Fruit{"Orange", true, nil}}
        ft.fruit = ft
        return ft
    }
    func NewApple() *Fruit {
        ft := &Fruit{"apple", true, nil}
        return ft
    }
    
    func (o *Orange) Eat() string {
        return "The orange is so sour!"
    }
    
    func main() {
        log.Println(NewApple().Eat())
        log.Println(NewApple().Wash().Eat())
        log.Println(NewOrange().Eat())
        log.Println(NewOrange().Wash().Eat())
    }
    
    0 讨论(0)
  • 2020-11-27 05:10

    Go does not support virtual method overriding. The design pattern you want to use is thus not directly supported by Go. It is considered bad practice because changing the implementation of A.Bar() would break all derived classes like B that assume A.Foo() will be called by A.Bar(). The design pattern you want to use will make your code brittle.

    The way to do it in Go would be to define a Fooer interface with a Foo() method. A Fooer would be passed as argument to Bar() or stored in a field of A and called by A.Bar(). To change the Foo action, change the Fooer value. This is called composition, and it is much better than changing Foo action by inheritance and method overriding.

    Here is an idiomatic way to do what you want to do in Go: https://play.golang.org/p/jJqXqmNUEHn. In this implementation, the Fooer is a member field of A that is initialized by a parameter of to the instance factory function NewA(). This design pattern is preferable when the Fooer doesn't change frequently during the lifetime of A. Otherwise, you may pass the Fooer as parameter of the Bar() method.

    This is how we change the behavior of Foo() in Go. It is called composition because you change the behavior of Bar() by changing the instances composing A.

    package main
    
    import (
        "fmt"
    )
    
    type Fooer interface {
        Foo()
    }
    
    type A struct {
        f Fooer
    }
    
    func (a *A) Bar() {
        a.f.Foo()
    }
    
    func NewA(f Fooer) *A {
        return &A{f: f}
    }
    
    type B struct {
    }
    
    func (b *B) Foo() {
        fmt.Println("B.Foo()")
    }
    
    type C struct {
    }
    
    func (c *C) Foo() {
        fmt.Println("C.Foo()")
    }
    
    func main() {
        a := NewA(new(B))
        a.Bar()
    
        a.f = &C{}
        a.Bar()
    }
    

    PS: Here is a possible implementation of the design pattern you wanted to implement for documentation purpose: https://play.golang.org/p/HugjIbYbout

    0 讨论(0)
  • 2020-11-27 05:17

    Been struggling with this myself. Found 2 solutions:

    1. Idiomatic Go way: implement the common "method" as external function with interface as argument.

       package main
      
       import "fmt"
      
       // Fooer has to Foo
       type Fooer interface {
           Foo()
       }
      
       // Bar is a proxy, that calls Foo of specific instance.
       func Bar(a Fooer) {
           a.Foo()
       }
      
       //////////////////////////////////////////////////////////////////////
       // usage
      
       func main() {
           b := &B{} // note it is a pointer
           // also there's no need to specify values for default-initialized fields.
           Bar(b) // prints: B.Foo()
       }
      
       //////////////////////////////////////////////////////////////////////
       // implementation
      
       // A is a "base class"        
       type A struct {
       }
      
       func (a *A) Foo() {
           fmt.Println("A.Foo()")
       }
      
       // B overrides methods of A
       type B struct {
           A
       }
      
       func (b *B) Foo() {
           fmt.Println("B.Foo()")
       }
      

    Try it on Go Playground: https://play.golang.org/p/2TbmHUs9_Dt

    1. Similar to your second option: interface hackery. However, since Bar() is not specific to A (it is common to A and B), let's move it to base class, and hide implementation details and all dangerous stuff:

       package main
      
       import "fmt"
      
       //////////////////////////////////////////////////////////////////////
       // Usage
      
       func main() {
           b := NewB()
           b.Bar() // prints: B.Foo()
      
           a := NewA()
           a.Bar() // prints: A.Foo()
       }
      
       //////////////////////////////////////////////////////////////////////
       // Implementation.
      
       // aBase is common "ancestor" for A and B.
       type aBase struct {
           ABCD // embed the interface. As it is just a pointer, it has to be initialized!
       }
      
       // Bar is common to A and B.
       func (a *aBase) Bar() {
           a.Foo() // aBase has no method Foo defined, so it calls Foo method of embedded interface.
       }
      
       // a class, not exported
       type a struct {
           aBase
       }
      
       func (a *a) Foo() {
           fmt.Println("A.Foo()")
       }
      
       // b class, not exported
       type b struct {
           aBase
       }
      
       func (b *b) Foo() {
           fmt.Println("B.Foo()")
       }
      
       //////////////////////////////////////////////////////////////////////
       // Now, public functions and methods.
      
       // ABCD describes all exported methods of A and B.
       type ABCD interface {
           Foo()
           Bar()
       }
      
       // NewA returns new struct a
       func NewA() ABCD {
           a := &a{}
           a.ABCD = a
           return a
       }
      
       // NewB returns new struct b
       func NewB() ABCD {
           b := &b{}
           b.ABCD = b
           return b
       }
      

    Try it on Go Playground: https://play.golang.org/p/0Zcs_arturP

    0 讨论(0)
  • 2020-11-27 05:20

    Coming from C++/Python, where OOP is much better represented, and discovering go (now everything is web or web related, right?!) I too stumbled upon this issue. I feel that OOP in go is only half baked. With embedding (struct's anonymous fields), methods of the inner type come along for free, inducing the idea of inheritance, only to learn later on the limitations. However, playing a bit with embedded interfaces within structs and with a bit of discipline, C++ like constructors, inheritance, polymorphism and methods override can be emulated.

    Considering the example - https://play.golang.org/p/6IPi3Mqw8_W

    package main import ( "bytes" "fmt" "log" "math" "unsafe" ) //Emulate C++ like polymorphysm in go, through template method design pattern //========================== Shape interface ============================== //like C++ abstract classes type Shape interface { Area() float32 //Shape's area Perimeter() float32 //Shape's perimeter Name() string //Shape's name (like rectangle, circle, square etc.) } //====================== PrintableShapeInfo ============================= type PrintableShapeInfo struct { Shape //like C++ inheritence, allthow go hasn't such a thing preetyPrintPrefix string } //Init a new PrintableShapeInfo object. The method is disctinct so that it can be called from other contextes as well // //Remark: emulates the C++ constructor init part func (printableShapeInfo *PrintableShapeInfo) Init(preetyPrintPrefix string) { printableShapeInfo.preetyPrintPrefix = preetyPrintPrefix } //The central method which emulates the template method design pattern. It prints some info about a shape by dynamically calling i.e. through pointers) the right methods // //Remark: allthough the design patterns best practices recommend to model a different concept, such as ShapeInfoPrinter, which takes a Shape interface and prints its info, //for the sake of showcasting the template method pattern, the "go's inheritange" like model was chosen func (printableShapeInfo *PrintableShapeInfo) PrintInfo() { log.Println("PrintableShapeInfo::PrintInfo") fmt.Printf("%s PrintableShapeInfo::PrintInfo - %s:\n", printableShapeInfo.preetyPrintPrefix, printableShapeInfo.Name()) //dynamically calls (i.e. through a pointer) a shape's Name method (like Rectangle.Name or Circle.Name or Square.Name) fmt.Printf("\tArea: %f\n", printableShapeInfo.Area()) //dynamically calls (i.e. through a pointer) a shape's Area method (like Rectangle.Area or Circle.Area or Square.Area) fmt.Printf("\tPerimeter: %f\n", printableShapeInfo.Perimeter()) //dynamically calls (i.e. through a pointer) a shape's Perimeter method (like Rectangle.Perimeter or Circle.Perimeter or Square.Perimeter) } //====================== Rectangle ============================= type Rectangle struct { PrintableShapeInfo //like C++ inheritence, allthow go hasn't such a thing width float32 //rectangle's width height float32 //rectangle's heigh } //Creats and init a new rectangle object and properly set it's Shape's interface methors set (similar to C++ class' vtable) // //Remark: emulates the C++ constructor func NewRectangle(width float32, height float32) *Rectangle { log.Println("NewRectangle") rectangle := new(Rectangle) //allocate data rectangle.Shape = rectangle //set the Shape's specific vtable with the Rectangle's methods. Critical for template method pattern rectangle.Init(width, height) //init class return rectangle } //Init a new rectangle object. The method is disctinct so that it can be called from other contextes as well (such as a square Init method. See bellow) // //Remark: emulates the C++ constructor init part func (rectangle *Rectangle) Init(width float32, height float32) { log.Println("Rectangle::Init") //call the base's PrintableShapeInfo struct Init method rectangle.PrintableShapeInfo.Init("###") rectangle.width = width rectangle.height = height } //Compute the rectangle's area func (rectangle *Rectangle) Area() float32 { log.Println("Rectangle::Area") return float32(rectangle.width * rectangle.height) } //Compute the rectangle's perimeter func (rectangle *Rectangle) Perimeter() float32 { log.Println("Rectangle::Perimeter") return float32(2 * (rectangle.width + rectangle.height)) } //Get the rectangle's object name func (rectangle *Rectangle) Name() string { log.Println("Rectangle::Name") return "rectangle" } //====================== Circle ============================= type Circle struct { PrintableShapeInfo //like C++ inheritence, allthow go hasn't such a thing radius float32 //circle's radius } //Creats and init a new circle object and properly set it's Shape's interface methors set (similar to C++ class' vtable) // //Remark: emulates the C++ constructor func NewCircle(radius float32) *Circle { log.Println("NewCircle") circle := new(Circle) //allocate data circle.Shape = circle //set the Shape's specific vtable with the Rectangle's methods. Critical for template method pattern circle.Init(radius) //init class return circle } //Init a new circle object. The method is disctinct so that it can be called from other contextes as well, if needed // //Remark: emulates the C++ constructor init part func (circle *Circle) Init(radius float32) { log.Println("Circle::Init") //call the base's PrintableShapeInfo struct Init method circle.PrintableShapeInfo.Init("ooo") circle.radius = radius } //Compute the circle's area func (circle *Circle) Area() float32 { log.Println("Circle::Area") return math.Pi * float32(circle.radius*circle.radius) } //Compute the circle's perimeter func (circle *Circle) Perimeter() float32 { log.Println("Circle::Perimeter") return 2 * math.Pi * float32(circle.radius) } //Get the circle's object name func (circle *Circle) Name() string { log.Println("Circle::Name") return "circle" } //====================== Rectangle ============================= //Implement Square in terms of Rectangle type Square struct { Rectangle //like C++ inheritence, allthow go hasn't such a thing } //Creats and init a new square object and properly set it's Shape's interface methors set (similar to C++ class' vtable) // //Remark: emulates the C++ constructor init func NewSquare(width float32) *Square { log.Println("NewSquare") square := new(Square) //allocate data square.Shape = square //set the Shape's specific vtable with the Rectangle's methods. Critical for template method pattern square.Init(width) //init class return square } //Init a new square object. The method is disctinct so that it can be called from other contextes as well, if needed // //Remark: emulates the C++ constructor init part func (square *Square) Init(width float32) { log.Println("Square::Init") //since the Rectangle field is anonymous it's nice that we can directly call it's un-overwritten methods but we can still access it, as named Rectangle, along with it's (even overwritten) methods square.Rectangle.Init(width, width) //call Rectangle's init to initialize it's members. Since Square is totaly implemented in Rectangle's terms, there nothing else needed } //Compute the square's area func (square *Square) Area() float32 { log.Println("Square::Area") //since the Rectangle field is anonymous it's nice that we can directly call it's un-overwritten methods but we can still access it, as named Rectangle, along with it's (even overwritten) methods return square.Rectangle.Area() } //Compute the square's perimeter func (square *Square) Perimeter() float32 { log.Println("Square::Perimeter") //since the Rectangle field is anonymous it's nice that we can directly call it's un-overwritten methods but we can still access it, as named Rectangle, along with it's (even overwritten) methods return square.Rectangle.Perimeter() } //Get the square's object name func (square *Square) Name() string { log.Println("Square::Name") return "square" } func main() { //initialize log subsystem so that we can display tham at the main end // bufWriter := bytes.NewBuffer() logStringWriter := bytes.NewBufferString("") log.SetOutput(logStringWriter) rectangle := NewRectangle(2, 3) //create a Rectangle object rectangle.PrintInfo() //should manifest polymorphism behavior by calling Rectangle's Area, Perimeter and Name methods circle := NewCircle(2) //create a Circle object circle.PrintInfo() //should manifest polymorphism behavior by calling Circle's Area, Perimeter and Name methods square := NewSquare(3) //create a Square object square.PrintInfo() //should manifest polymorphism behavior by calling Square's Area, Perimeter and Name methods //print constructs sizes fmt.Printf(` Go constructs sizes: Shape interface size as seen by Rectangle struct: %d `, unsafe.Sizeof(rectangle.Shape)) fmt.Printf("\tRectangle struct size: %d", unsafe.Sizeof(rectangle)) fmt.Printf(` Shape interface size as seen by Circle struct: %d `, unsafe.Sizeof(circle.Shape)) fmt.Printf("\tCircle struct size: %d", unsafe.Sizeof(circle)) fmt.Printf(` Shape interface size as seen by Square struct: %d `, unsafe.Sizeof(square.Shape)) fmt.Printf("\tCircle struct size: %d", unsafe.Sizeof(square)) //print the logs fmt.Println("\n\nDumping traces") fmt.Print(logStringWriter) return }

    The central method (template method) is PrintInfo which, called for any defined shape, works as expected, by calling the right Area, Perimeter and Name methods. Ex. circle.PrintInfo() will call circle.Area, circle.Perimeter and circle.Name.

    The constructor functions, NewRectangle, NewCircle and NewSquare construct shape objects and basically is split in three steps:

    • space allocation
    • methods set (C++ like vtable) init, needed for polymorphic behavior
    • struct members initialization, through Init methods

    The struct member initialization is a distinct step for a better code reuse. For example, Rectangle Init calls the base PrintableShapeInfo Init method while the Square Init method calls the base Rectangle Init (which calls PrintableShapeInfo Init, as said before).

    Also, due to interfaces embedding, the object sizes increases only a bit, with a pair of pointers to the methods set and data area as can be seen in the example output.

    I think the code looks pretty decent and the only concern being if specifically setting the Shape's interface method set (as the case in NewRectangle, NewCircle and NewSquare functions) would trigger some side effects as the code appears to work correctly?!

    0 讨论(0)
  • 2020-11-27 05:26
    package main
    
    import (
        "fmt"
    )
    
    
    //-- polymorphism in work
    
    // children specification by methods signatures
    // you should define overridable methods here
    type AChildInterface interface {
        Foo()
    }
    
    type A struct {
        child AChildInterface
    }
    
    //-- /polymorphism in work
    
    
    // hard A.Bar method
    func (a *A) Bar() {
        a.child.Foo() // Foo() will be overwritten = implemented in a specified child
    }
    
    
    //-- default implementations of changeable methods
    
    type ADefaults struct{}
    
    func (ad ADefaults) Foo() {
        fmt.Println("A.Foo()")
    }
    
    //-- /default
    
    
    //-- specified child
    
    type B struct {
        ADefaults // implement default A methods from ADefaults, not necessary in this example
    }
    
    // overwrite specified method
    func (b B) Foo() {
        fmt.Println("B.Foo()")
    }
    
    //-- /specified child
    
    func main() {
        a := A{ADefaults{}}
        a.Bar()
    
        // Golang-style inheritance = embedding child
        b := A{B{}} // note: we created __Parent__ with specified __Child__ to change behavior
        b.Bar()
    }
    

    Output:

    A.Foo()
    B.Foo()
    
    0 讨论(0)
提交回复
热议问题