The code below is really self-explanatory.
How come I can say that the result of CreateLion(), a pointer to a struct that implements the Cat interface, is an instance of
Works fine with a few changes. Check it out here: https://play.golang.org/p/ECSpoOIuzEx
package main
import "fmt"
func main() {
lion := CreateLion() // Go idomatic style recommends
// allowing the compiler to divine the type
lion.Meow()
CatFactory := CreateLion
_ = CatFactory // Go doesn't like unused variables and fails the build
obj := CatFactory() // exercising our factory method
obj.Meow()
}
type Cat interface {
Meow()
}
type Lion struct {}
func (l Lion) Meow() {
fmt.Println("Roar")
}
// define a functor that returns a Cat interface
type CatFactory func() Cat
// define a function that returns a pointer to a Lion struct
func CreateLion() *Lion {
return &Lion{}
}
Also, though Go doesn't have Java style interfaces, it does have interfaces and you can achieve polymorphism, but the types are known at compile time.
You can model an "Is A" relationship, if both types implement the same interface. However it doesn't enforce the interface until you pass the object into a function that accepts that interface type. So if you imagine implementing the Strategy pattern, when you're passing in the strategy object matching interface "Cat", that function will accept a "Lion" object, or any other class that implements a Meow function with the correct signature.
Also, factory methods are definitely necessary and useful in Go. In fact, instead of constructors, in Go, you use factory functions to construct your objects.