作業内容でクラス分けするな。担当内容で分けろ

**仕様書無しさん** · 2018/06/10(日) 00:51:50.22

レストランにて

【×】駄目なクラス分け

皮を剥く係
包丁で切る係
鍋で煮込む係
フライパンで焼く係

【○】正しいクラス分け

カレーを作る係
シチューを作る係
ステーキ作る係
焼きそばを作る係

**仕様書無しさん** · 2018/06/14(木) 08:08:13.58

>>19
根拠と君の意見を述べよ

**仕様書無しさん** · 2018/06/14(木) 12:34:11.19

>>20
うるさいハゲ

**仕様書無しさん** · 2018/06/14(木) 15:10:23.67

根拠であって毛根ではない

**仕様書無しさん** · 2018/06/14(木) 19:38:24.96

「うるさいハゲ」は根拠にはならないというのだろうか？

**仕様書無しさん** · 2018/06/14(木) 19:41:00.58

入力はたくさん、出力はひとつ

**仕様書無しさん** · 2018/06/14(木) 22:55:59.39

揚げ物係
焼き物係
肉料理係
みたいな感じだな

**仕様書無しさん** · 2018/06/20(水) 05:02:55.81

>>1
両方クラス分けすればいいじゃん
それぞれ必要なデータも作業のレベルも違うんだから

**仕様書無しさん** · 2018/06/26(火) 22:13:01.76

メソッドの切り口をどのへんにするかでいつも死ぬほど悩む
業務機能として切り口つくるかプログラム的な切り口にするかで
だいたい一貫性が保てずぐちゃぐちゃになる

ユーザーの種類を取得するメソッドはgetUserType()にするべきか
DBからデータ引っ張ってくるんだからgetUser()として呼び出し側でuser.getType()とするべきか？

**仕様書無しさん** · 2018/07/01(日) 07:36:00.61

>>27
そこは一貫性いらないと思う。
どうしても一貫性がいるなら後者にせざるを得ない（全プロパティ分メソッドをつくる？まさか）。
でもユーザタイプだけよく使うからメソッドにするよ、ってことはあり得る。

**仕様書無しさん** · 2018/07/02(月) 23:07:15.66

>>27
ユーザーの属性が多いならユーザークラスを作るかんじやな
少ないならメソッドだけでええんやないかな