Go does not provide the typical, type-driven notion of subclassing,
    but it does have the ability to “borrow” pieces of an implementation by embedding types within a struct or interface

    interface embedding
    Embed two interfaces to form a new one. It is a union of the embedded interfaces.
    Only interfaces can be embedded within interfaces.

    1. // io package
    2. type Reader interface {
    3.     Read(p []byte) (n int, err error)
    4. }
    6. type Writer interface {
    7.     Write(p []byte) (n int, err error)
    8. }
    10. // ReadWriter is the interface that combines the Reader and Writer interfaces.
    11. type ReadWriter interface {
    12.     Reader
    13.     Writer
    14. }


    struct embedding**
    bufio package
    list the types within the struct but does not give them field names

    1. // ReadWriter stores pointers to a Reader and a Writer.
    2. // It implements io.ReadWriter.
    3. type ReadWriter struct {
    4.     *Reader  // *bufio.Reader
    5.     *Writer  // *bufio.Writer
    6. }

    bufio.ReadWriter not only has the methods of bufio.Reader and bufio.Writer, but also satisfies all three interfaces: io.Reader, io.Writer, and io.ReadWriter.

    an embedded field alongside a regular, name field

    1. type Job struct {
    2.     Command string
    3.     *log.Logger
    4. }
    6. // initializing
    7. func NewJob(command string, logger *log.Logger) *Job {
    8.     return &Job{command, logger}
    9. }
    10. job := &Job{command, log.New(os.Stderr, "Job: ", log.Ldate)}
    12. // The Job type has the methods of *log.Logger
    13. job.Println("starting now...")
    15. //refer to an embedded field directly, using type name
    16. job.Logger.Println("refer directly")


    the rules to resolve name conflicts**

    1. A field or method X hides any other item X in a more deeply nested part of the type.
    2. If the same name appears at the same nesting level, it is usually an error;

    However, if the duplicate name is never mentioned outside the type definition, it is OK. (NOT in the same struct)

    it is OK, inner field is never mentioned outside the type definition

    1. type inner1 struct {
    2.     field string
    3. }
    5. type inner2 struct {
    6.     field string
    7. }
    9. type outer struct {
    10.     inner1
    11.     inner2
    12. }
    14. func main() {
    15.     out := outer{
    16.         inner1{"inner1"},
    17.         inner2{"inner2"},
    18.     }
    19.     fmt.Println(out)
    20. }

    Ambiguous reference
    image.png
    Duplicate field
    image.png