Golang OOP、继承、组合、接口

Class Human {
 name:string
 age:int
 function eat(){}
 function speak(){}
}
 
Class Man extends Human {
 function fish(){}
 function drink(){}
}
 

package main
 
import "fmt"
 
func main(){
 var h Human
 
 s := Student{Grade: 1, Major: "English", Human: Human{Name: "Jason", Age: 12, Being: Being{IsLive: true}}}
 fmt.Println("student:", s)
 fmt.Println("student:", s.Name, ", isLive:", s.IsLive, ", age:", s.Age, ", grade:", s.Grade, ", major:", s.Major)
 
 //h = s // cannot use s (type Student) as type Human in assignment
 fmt.Println(h)
 
 //Heal(s) // cannot use s (type Student) as type Being in argument to Heal
 Heal(s.Human.Being) // true
 
 s.Drink()
 s.Eat()
}
 
 
type Car struct {
 Color string
 SeatCount int
}
 
type Being struct {
 IsLive bool
}
 
type Human struct {
 Being
 Name string
 Age int
}
 
func (h Human) Eat(){
 fmt.Println("human eating...")
 h.Drink()
}
 
func (h Human) Drink(){
 fmt.Println("human drinking...")
}
 
func (h Human) Move(){
 fmt.Println("human moving...")
}
 
type Student struct {
 Human
 Grade int
 Major string
}
 
func (s Student) Drink(){
 fmt.Println("student drinking...")
}
 
type Teacher struct {
 Human
 School string
 Major string
 Grade int
 Salary int
}
 
func (s Teacher) Drink(){
 fmt.Println("teacher drinking...")
}
 
 
type IEat interface {
 Eat()
}
 
type IMove interface {
 Move()
}
 
type IDrink interface {
 Drink()
}
 
 
func Heal(b Being){
 fmt.Println(b.IsLive)
}

student: {{{true} Jason 12} 1 English}
student: Jason , isLive: true , age: 12 , grade: 1 , major: English
{{false} 0}
true
student drinking...
human eating...
human drinking...

代码处理的是各种数据。对于强类型语言来说,非常希望一批数据都是单一类型的,这样它们的行为完全一致。但世界是复杂的,很多时候数据可能包含不同的类型,却有一个或多个共同点。这些共同点就是抽象的基础。单一继承关系解决了 is-a 也就是定义问题,因此可以把子类当做父类来对待。但对于父类不同但又具有某些共同行为的数据,单一继承就不能解决了。单一继承构造的是树状结构,而现实世界中更常见的是网状结构。

于是有了接口。接口是在某一个方面的抽象,也可以看做具有某些相同行为的事物的标签。

但不同于继承,接口是松散的结构,它不和定义绑定。从这一点上来说,Duck Type 相比传统的 extends 是更加松耦合的方式,可以同时从多个维度对数据进行抽象,找出它们的共同点,使用同一套逻辑来处理。

interface IEnglishSpeaker {
 ListenEnglish()
 ReadEnglish()
 SpeakEnglish()
 WriteEnglish()
}

// 接上面的例子
 
v1, b := interface{}(s).(Car)
fmt.Println(v1, b)
 
v2, b := interface{}(s).(Being)
fmt.Println(v2, b)
 
v3, b := interface{}(s).(Human)
fmt.Println(v3, b)
 
v4, b := interface{}(s).(Student)
fmt.Println(v4, b)
 
v5, b := interface{}(s).(IDrink)
fmt.Println(v5, b)
 
v6, b := interface{}(s).(IEat)
fmt.Println(v6, b)
 
v7, b := interface{}(s).(IMove)
fmt.Println(v7, b)
 
v8, b := interface{}(s).(int)
fmt.Println(v8, b)

{ 0} false
{false} false
{{false} 0} false
{{{true} Jason 12} 1 English} true
{{{true} Jason 12} 1 English} true
{{{true} Jason 12} 1 English} true
<nil> false
0 false

s1 := Student{Grade: 1, Major: "English", Human: Human{Name: "Jason", Age: 12, Being: Being{IsLive: true}}}
s2 := Student{Grade: 1, Major: "English", Human: Human{Name: "Tom", Age: 13, Being: Being{IsLive: true}}}
s3 := Student{Grade: 1, Major: "English", Human: Human{Name: "Mike", Age: 14, Being: Being{IsLive: true}}}
t1 := Teacher{Grade: 1, Major: "English", Salary: 2000, Human: Human{Name: "Michael", Age: 34, Being: Being{IsLive: true}}}
t2 := Teacher{Grade: 1, Major: "English", Salary: 3000, Human: Human{Name: "Tony", Age: 31, Being: Being{IsLive: true}}}
t3 := Teacher{Grade: 1, Major: "English", Salary: 4000, Human: Human{Name: "Ivy", Age: 40, Being: Being{IsLive: true}}}
drinkers := []IDrink{s1, s2, s3, t1, t2, t3}
 
for _, v := range drinkers {
 switch t := v.(type) {
 case Student:
 fmt.Println(t.Name, "is a Student, he/she needs more homework.")
 case Teacher:
 fmt.Println(t.Name, "is a Teacher, he/she needs more jobs.")
 default:
 fmt.Println("Invalid Human being:", t)
 }
}

Jason is a Student, he/she needs more homework.
Tom is a Student, he/she needs more homework.
Mike is a Student, he/she needs more homework.
Michael is a Teacher, he/she needs more jobs.
Tony is a Teacher, he/she needs more jobs.
Ivy is a Teacher, he/she needs more jobs.

I once attended a Java user group meeting where James Gosling (Java’s inventor) was the featured speaker.

During the memorable Q&A session, someone asked him: "If you could do Java over again, what would you change?"

"I’d leave out classes," he replied. After the laughter died down, he explained that the real problem wasn’t classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible.