- 入力フォーマット
- 登録処理の中でのデータモデル
- 出力フォーマット
が分離していて、それがコード上の構造で表現されているのがよいと思います。 分離すると、どこかで結合しないといけないのでマッピングが発生します。 そこは互いのインターフェイスをどう解釈するかという表現なので明示的になっているほうがよいと思います。
実装の手続きよりも具体的な役割 (具体的というのは詳細な実装という意味ではなくて、この場の役割の文脈をくわしく表現するという意味) を名前としてつけるほうがよいクラス名となります。
Input も Material も一般的な単語すぎて何も言っていないに近いので、もう少し自分がなんと名付けるかという意志をはっきりと持った名前付けをしてほしいかんじです。手段よりももっと目的 (もたらされる結果) によった名前をつけたほうがよさそう。
Item が一般名詞で意味がぼんやりしているのが、もう一息！ってところですね。 なにを抽象化しているのかがもう少し意識的になってくるといいと思います。 外へ提供するサービス (公開されたAPI) として役割を名前で表現して、 中へ閉じるものとしてデータ構造が明示されてくると閉じたいものと見せたいものがはっきりしてきてよりよくなります。
のちほど口頭でも説明しますが、様子を見守っている人向けにコメントでも書いておくと、 クラス名を一般的な名称でつけがちなのは頭の中でモデリングが不十分なのか、 もしくは名前付けの悪いクセのように思えます。 一般的な名称をつけると、なんとなくそれっぽく見えます。ただ、それは何も拒否しないからです。
クラス設計というのは、責務の所在判断なので、基本的には切り捨てる作業です。そのクラスにやらせること (責務) を決めるということは、やらないこと (＝やらせてはいけないこと) を決めることでもあります。 よい名前は、一つの文脈へクラスを縛ります。それによって、「そうじゃないもの」がそのクラスに存在することに違和感を覚え、自分がつくったクラスのその後の姿を規定できます。結果として、良い名前が将来にわたって適切なクラス設計へ導きます。 どうにでもとれる名称にしてしまうと、なんでも入れてOKになってしまい、クラスの意図しない責務まで背負わされ肥大します。
一つの文脈へクラスを縛るということは、どんな文脈を期待しているかを自分で明確に決めなければなりません。そのためにモデリングの作業が必要になります。どんな役割を分担してアプリケーションを成り立たせるのか、それを自分の中で明確にして、さらに名前で表現したものがクラスです。
ということで、その辺を一つ一つ見ながらレビューとペアプロする会をやってぼちぼち仕上げましょうか。