Reputation: 839
Suppose I have two pets, a cat named Lucy and a dog named Fido. I have taught them both the same trick, "speak".
In the future I would like to obtain more pets, and teach them different tricks, so in anticipation, I've coded to an interface:
package main
import "fmt"
type Pet interface {
speak() string
}
type Dog struct {
speech string
}
type Cat struct {
speech string
}
func (c Cat) speak() string {
return c.speech
}
func (d Dog) speak() string {
return d.speech
}
func getSpeech(p Pet) string {
return p.speak()
}
func main() {
Fido := Dog{"woof"}
Lucy := Cat{"meow"}
fmt.Println("Fido says:", getSpeech(Fido)) // Fido says: woof
fmt.Println("Lucy says:", getSpeech(Lucy)) // Lucy says: meow
}
Now, although this works well, it seems unnecessarily verbose. I'm clearly repeating myself. Also, assuming all Dogs say "woof" and all Cats say "meow", is it idiomatic to initialize the string inside the struct?
How would you re-factor this code to be more DRY without losing the benefit of an interface?
Upvotes: 1
Views: 380
Reputation:
You could just do this.
package main
import "fmt"
type Pet interface{ speak() string }
type Speaker struct{ Saying string }
func (s Speaker) speak() string { return s.Saying }
func getSpeech(p Pet) string { return p.speak() }
func main() {
Fido := Speaker{Saying: "woof"}
Lucy := Speaker{Saying: "meow"}
fmt.Println("Fido says:", getSpeech(Fido)) // Fido says: woof
fmt.Println("Lucy says:", getSpeech(Lucy)) // Lucy says: meow
}
I try not to make code too DRY that it chafes. I'm okay with code that duplicates twice and only factor if it's repeated a third time.
Upvotes: 0
Reputation: 109448
You can embed a base type in some cases to delegate common fields and methods. This is not inheritance, it is only a form of automatic delegation via composition. Don't try to use this to create type hierarchies like you would in a java-style OOP language.
Here you can delegate the speak
method to the Speaker
type. In practice this is less useful because the Speaker
and its methods have no relationship to the struct where they are embedded, i.e. a Speaker doesn't know which type it's speaking for, nor which individual instance.
https://play.golang.org/p/Bof92jZsNh
type Speaker struct {
Saying string
}
func (s Speaker) speak() string {
return s.Saying
}
type Pet interface {
speak() string
}
type Dog struct {
Speaker
}
type Cat struct {
Speaker
}
func getSpeech(p Pet) string {
return p.speak()
}
func main() {
Fido := Dog{Speaker{Saying: "woof"}}
Lucy := Cat{Speaker{Saying: "meow"}}
fmt.Println("Fido says:", getSpeech(Fido)) // Fido says: woof
fmt.Println("Lucy says:", getSpeech(Lucy)) // Lucy says: meow
}
Upvotes: 6
Reputation: 42478
First: I cannot see any repetition in your code: You have cats and dogs and each cat may say something and each dog may something. If this is not the case and your assumption is true
If all all Dogs woof and all cat meow how about:
const dogTalk = "woof"
func (d Dog) speak() string { return dogTalk; }
// or even
func (d Cat) speak() string { return "meow"; }
(And: Don't code Java in Go)
Upvotes: 6