GoSudaInterfejsy i osadzanie struktur w Go: różnice względem dziedziczenia klas oraz projektowanie oparte na kompozycji
Przegląd
Interfejsy w Go umożliwiają łatwe posiadanie przez wiele struktur funkcji o tych samych argumentach i typach zwracanych, jednak różnią się one od sposobu, w jaki słowo kluczowe extends w Javie odpowiednio rozszerza i nadpisuje zachowanie tych funkcji. Aby nie pomylić kompozycyjnego ponownego wykorzystania kodu w Go z dziedziczeniem, trzeba je prawidłowo zrozumieć, jednak od razu osiągnięcie w pełni teoretycznego zrozumienia jest trudne. Przyjrzyjmy się temu na scenariuszach, w których łatwo popełnić błąd.
Typowe błędy
Początkujący mogą popełniać następujące błędy.
1package main
2import (
3 "fmt"
4 "strings"
5)
6
7type Fruits interface {
8 GetBrix() float64
9 GetName() string
10 SetLabel()
11 GetLabel(string) string
12 PrintAll()
13}
14
15type Apple struct {
16 Label string
17 Name string
18 Brix float64
19}
20
21type Watermelon struct {
22 Label string
23 Name string
24 Brix float64
25}
26
27func (a *Apple) PrintAll() {
28 fmt.Printf("Fruit: %s, Label: %s, Brix: %v\n", a.Name, a.Label, a.Brix)
29}
30
31const (
32 NO_LABEL = "EMPTY LABEL"
33)
34
35func (a *Apple) SetLabel(lbl string) {
36 a.Brix = 14.5;
37 a.Name = "apple";
38 lbl_lower := strings.ToLower(lbl)
39 if strings.Contains(lbl_lower, a.Name) {
40 fmt.Println("Succeed: Label was ", lbl)
41 a.Label = lbl;
42 } else {
43 fmt.Println("Failed: Label was ", lbl)
44 a.Label = NO_LABEL;
45 }
46}
47
48func (w *Watermelon) SetLabel(lbl string) {
49 w.Brix = 10;
50 w.Name = "watermelon";
51 lbl_lower := strings.ToLower(lbl)
52 if strings.Contains(lbl_lower, w.Name) {
53 w.Label = lbl;
54 } else {
55 w.Label = NO_LABEL;
56 }
57}
58
59func main() {
60 fmt.Println("Inheritance test #1")
61 apple := new(Apple)
62 watermelon := apple
63 apple.SetLabel("Apple_1")
64 fmt.Println("Apple, before copied to Watermelon")
65 apple.PrintAll()
66 watermelon.SetLabel("WaterMelon_2")
67 fmt.Println("Apple, after copied to Watermelon")
68 apple.PrintAll()
69 fmt.Println("Watermelon, which inherited Apple's Method")
70 watermelon.PrintAll()
71}
Ktoś, kto uważa, że Go stosuje tradycyjne dziedziczenie, może sądzić, że powyższy kod nie sprawia problemów. Jednak jego wynik wygląda następująco.
1Inheritance test #1
2Succeed: Label was Apple_1
3Apple, before copied to Watermelon
4Fruit: apple, Label: Apple_1, Brix: 14.5
5Failed: Label was WaterMelon_2
6Apple, after copied to Watermelon
7Fruit: apple, Label: EMPTY LABEL, Brix: 14.5
8Watermelon, which inherited Apple's Method
9Fruit: apple, Label: EMPTY LABEL, Brix: 14.5
Tutaj działanie Go staje się po prostu jasne.
1watermelon := apple
Ten kod wcale nie przekształca Apple w klasę Watermelon. Zmienna watermelon jest jedynie wskaźnikiem na apple.
Podkreślmy to ponownie: Go nie stosuje tradycyjnej koncepcji dziedziczenia.
Pisanie kodu z takim nieporozumieniem prowadzi do poważnych błędów, takich jak bezsensowne tworzenie wskaźników czy nieoczekiwane kopiowanie funkcji dla innych struktur.
Jak więc wygląda wzorcowy kod?
Odpowiedni przykład w języku Go
1package main
2import (
3 "fmt"
4 "strings"
5)
6
7type Fruits interface {
8 GetBrix() float64
9 GetName() string
10 SetLabel()
11 GetLabel(string) string
12 PrintAll()
13}
14
15type BaseFruit struct {
16 Name string
17 Brix float64
18}
19
20type Apple struct {
21 Label string
22 Fruit BaseFruit
23}
24
25type Watermelon struct {
26 Label string
27 Fruit BaseFruit
28
29}
30
31func (b *BaseFruit) PrintAll() {
32 fmt.Printf("Fruit: %s, Brix: %v\n", b.Name, b.Brix)
33}
34
35
36const (
37 NO_LABEL = "EMPTY LABEL"
38)
39
40func (a *Apple) SetLabel(lbl string) {
41 a.Fruit.Brix = 14.5;
42 a.Fruit.Name = "apple";
43 lbl_lower := strings.ToLower(lbl)
44 if strings.Contains(lbl_lower, a.Fruit.Name) {
45 fmt.Println("Succeed: Label was ", lbl)
46 a.Label = lbl;
47 } else {
48 fmt.Println("Failed: Label was ", lbl)
49 a.Label = NO_LABEL;
50 }
51 fmt.Printf("Fruit %s label set to %s\n", a.Fruit.Name, a.Label);
52 a.Fruit.PrintAll()
53}
54
55func (w *Watermelon) SetLabel(lbl string) {
56 w.Fruit.Brix = 10;
57 w.Fruit.Name = "Watermelon";
58 lbl_lower := strings.ToLower(lbl)
59 if strings.Contains(lbl_lower, w.Fruit.Name) {
60 w.Label = lbl;
61 } else {
62 w.Label = NO_LABEL;
63 }
64 fmt.Printf("Fruit %s label set to %s\n", w.Fruit.Name, w.Label);
65 w.Fruit.PrintAll()
66}
67
68func main() {
69 apple := new(Apple)
70 watermelon := new(Watermelon)
71 apple.SetLabel("Apple_1")
72 watermelon.SetLabel("WaterMelon_2")
73}
Jednak w Go można też sprawić, by wyglądało to jak dziedziczenie. Jest to przykład osadzania anonimowego. Jeśli wewnętrzną strukturę zadeklarujemy jako strukturę bez nazwy, możliwe jest to właśnie w ten sposób. W takim przypadku można uzyskiwać dostęp do pól struktury podrzędnej nawet bez jawnego odwoływania się do niej. Wzorzec, w którym pola struktury podrzędnej są awansowane do struktury nadrzędnej, może w niektórych przypadkach poprawić czytelność. Jednak w sytuacjach, gdy struktura podrzędna powinna być jawnie widoczna, zalecamy jego niestosowanie.
1package main
2import (
3 "fmt"
4 "strings"
5)
6
7type Fruits interface {
8 GetBrix() float64
9 GetName() string
10 SetLabel()
11 GetLabel(string) string
12 PrintAll()
13}
14
15type BaseFruit struct {
16 Name string
17 Brix float64
18}
19
20type Apple struct {
21 Label string
22 BaseFruit
23}
24
25type Watermelon struct {
26 Label string
27 BaseFruit
28
29}
30
31func (b *BaseFruit) PrintAll() {
32 fmt.Printf("Fruit: %s, Brix: %v\n", b.Name, b.Brix)
33}
34
35
36const (
37 NO_LABEL = "EMPTY LABEL"
38)
39
40func (a *Apple) SetLabel(lbl string) {
41 a.Brix = 14.5;
42 a.Name = "apple";
43 lbl_lower := strings.ToLower(lbl)
44 if strings.Contains(lbl_lower, a.Name) {
45 fmt.Println("Succeed: Label was ", lbl)
46 a.Label = lbl;
47 } else {
48 fmt.Println("Failed: Label was ", lbl)
49 a.Label = NO_LABEL;
50 }
51 fmt.Printf("Fruit %s label set to %s\n", a.Name, a.Label);
52 a.PrintAll()
53}
54
55func (w *Watermelon) SetLabel(lbl string) {
56 w.Brix = 10;
57 w.Name = "Watermelon";
58 lbl_lower := strings.ToLower(lbl)
59 if strings.Contains(lbl_lower, w.Name) {
60 w.Label = lbl;
61 } else {
62 w.Label = NO_LABEL;
63 }
64 fmt.Printf("Fruit %s label set to %s\n", w.Name, w.Label);
65 w.PrintAll()
66}
67
68func main() {
69 apple := new(Apple)
70 watermelon := new(Watermelon)
71 apple.SetLabel("Apple_1")
72 watermelon.SetLabel("WaterMelon_2")
73}
W tym przykładzie widoczna jest następująca różnica.
1w.PrintAll() // Wywołanie automatycznie awansowane przez strukturę bez nazwy, a nie w.Fruit.PrintAll()
Oba przykłady wskazują na następujące istotne kwestie:
- main powinien być prosty, a funkcje podzielone według funkcjonalności
- Różne struktury powinny reprezentować różne obiekty
- Gdy potrzebne jest współdzielenie, należy użyć struktury wewnętrznej
Jakie korzyści płyną z takiej filozofii programowania?
Zalety
- Wyraźne rozróżnienie metod, które wymagają współdzielenia, od tych, które go nie wymagają
- Rozdzielenie odpowiedzialności między poszczególne struktury i metody
- Kod strukturalnie podzielony zgodnie z wymaganą specyfikacją funkcji
Na początku język Go, różniący się od tradycyjnego OOP, może wydawać się nieznajomy, jednak po oswojeniu się z nim umożliwia pisanie programów w sposób jawny.
Podsumowanie
- Izolujmy odpowiedzialność
- Dzielmy kod szczegółowo na poziomie struktur
- Metod nie należy rozumieć jak klas abstrakcyjnych z Javy
- Piszmy jawny i konkretny kod Język Go powinien być traktowany jako prostszy i bardziej przejrzysty niż tradycyjny model OOP, a poszczególne elementy należy obsługiwać osobno. Zamiast programować w sposób rozszerzalny, piszmy kod etapami i w sposób strukturalnie rozdzielony.