回答編集履歴
1
追記
test
CHANGED
|
@@ -15,3 +15,111 @@
|
|
|
15
15
|
DBに接続して売れ筋商品の情報とマスタIDを元に、
|
|
16
16
|
|
|
17
17
|
自分でfor文回してマスタの商品名・発売日等の情報を取得する必要があります。
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
追記：ItemRepositoryクラスに関して
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
素晴らしい！
|
|
30
|
+
|
|
31
|
+
行クラスとテーブルクラスもちゃんと分かれていますし、こいつ単体でいえば何も言うことはありません。
|
|
32
|
+
|
|
33
|
+
|
|
34
|
+
|
|
35
|
+
> コンストラクタでItemのインスタンスをセットしてるのがちょっとイケてない気がしています。
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
現在形で特に問題ないと思います。
|
|
40
|
+
|
|
41
|
+
まぁ、マスターのデータ更新でプログラムの行数が増減するのはよろしくないので、
|
|
42
|
+
|
|
43
|
+
外部ファイル化させてさせてうまいことやる設計の方がクールでしょう。
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
> 行クラスをもっと活かす
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
もしfindBySlugの中身がforeachでぶん回して`if($item->getSlug() === $slug)`とかやってたらNGです。
|
|
52
|
+
|
|
53
|
+
ItemRepositoryクラスがやるべきことは、個々のItemさんに挙手してもらうことです。
|
|
54
|
+
|
|
55
|
+
こうすると例外パターンが出現した時にロジックを変更する必要があるのは常にItemとなるので、
|
|
56
|
+
|
|
57
|
+
問題の切り分けが楽になります。
|
|
58
|
+
|
|
59
|
+
|
|
60
|
+
|
|
61
|
+
```PHP
|
|
62
|
+
|
|
63
|
+
class Item {
|
|
64
|
+
|
|
65
|
+
function slug_is($it) {
|
|
66
|
+
|
|
67
|
+
return $this->slug === $it;
|
|
68
|
+
|
|
69
|
+
}
|
|
70
|
+
|
|
71
|
+
}
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
class ItemRepository {
|
|
76
|
+
|
|
77
|
+
function find_by_slug($slug) {
|
|
78
|
+
|
|
79
|
+
return array_filter($this->items, function($it) use($slug){return $it->slug_is($slug);});
|
|
80
|
+
|
|
81
|
+
}
|
|
82
|
+
|
|
83
|
+
}
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
|
|
87
|
+
|
|
88
|
+
|
|
89
|
+
> もし更に改良を加える場合
|
|
90
|
+
|
|
91
|
+
|
|
92
|
+
|
|
93
|
+
結論から言うと、良い抽象化とマジックメソッドが鍵となるでしょう。
|
|
94
|
+
|
|
95
|
+
考える方向性としては同じようなテーブル的なものを複数作成する必要が出てきた場合の考慮でしょう。
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+
|
|
99
|
+
例えば似たようなまた別のテーブルが必要になったら、
|
|
100
|
+
|
|
101
|
+
プログラムの設計は統一すべきなので似たような構造で作りますよね？
|
|
102
|
+
|
|
103
|
+
そうすると、コンストラクタメソッドの引数がバラバラになってまず困るわけですよ。
|
|
104
|
+
|
|
105
|
+
|
|
106
|
+
|
|
107
|
+
また、変数名も意識したほうが良いかもしれません。
|
|
108
|
+
|
|
109
|
+
ItemRepositoryクラスにとってのレコードとはitemsでこれはこれで具体的で二重丸な良い名前ですが、
|
|
110
|
+
|
|
111
|
+
担当者リストのStafRepositoryクラスが新設されたら同じようにitemsでいきますか？stafsになりますか？
|
|
112
|
+
|
|
113
|
+
|
|
114
|
+
|
|
115
|
+
もし私が仮に後輩にレビューして修正指示を出すのであれば、
|
|
116
|
+
|
|
117
|
+
重複部分を纏めてcommonRepositoryという汎用クラスを作成して、
|
|
118
|
+
|
|
119
|
+
itemsではなく、recordsという変数名で管理するように指示します。
|
|
120
|
+
|
|
121
|
+
|
|
122
|
+
|
|
123
|
+
もしくはカラムの構造が変化した場合の考慮です。
|
|
124
|
+
|
|
125
|
+
カラムをちょっと弄るだけでも10行単位で変わりますよね？
|