【RPG_評価03】つくる・迷い・考えた・記録

週の半ば、水曜日です。

予告通り、記録を残したいと思います。

今回はnoteストックがほぼなく、当日に頑張って内容を書いた結果・・。実装の時間が取れませんでした、反省してます。

・・反省は次に活かすためにある。さて、振り返っていきましょう。

前回のハイライト

・要求に対してざっくりと設計に落とし込む

これだけでした。やったことは色々ありますが、一言で終わるのも悲しいものです・・。興味がありましたら、前回の記事をご覧ください。

さて、今週の作業は・・

ドメイン設計として作ったモデルクラスを作成するところで終わりました。

あまり振り返る内容がないかと思っていましたが、たったこれだけでも「失敗をしたな・・」と感じている部分があります。ですので、そのことに関して書いていきます。良ければお付き合いください。

目に見える成果・動かせる成果は大事

まずやったことは、ドメインモデルのクラスを作りました。

「クラス名どうしようかな・・」
「この単語を英語にするとどうなる？」とググりながら・・。

それに伴い、コンストラクタも作りました。

ここで困ったことが。コンストラクタのアクセス修飾子どうしよう…。

「どこまでそのメソッドやコンストラクタを呼び出すことができるか」が「アクセス修飾子」という設定なのですが、実際に作ってみないと分からない。結局、コメントを残して未来の自分に託しました。

この進め方は、全く間違いではありません。というよりも、実装の順番なんて、自由で良いんですよ。結果、出来上がっていれば良いんですから。

私がやりたいことは、もっとも効率的だと思われる方法を見つけ出すということです。そのことを踏まえると、今回やった進め方よりも良い方法があるのでは・・と考え始めました。

思考を巡らせた結果、下記の進め方の方が良いのでは・・という結論に至りました。

1. ドメインモデルのクラス(本当に中身が空) を作る
2. サービスレベルのクラスを作り、必要なメソッドを作る
3. そのメソッドに必要なクラスを作る
4. ドメインモデルのクラスに具体的な値とコンストラクタを作る
5. 4の作業によって発生したサービスクラスのメソッドのエラーを解消する

この進め方には、二つメリットがあります。

一つは、冗長かな・・と思うクラスを後から作る必要がない。
もう一つは、複数人で作業をした場合です。

例えば、この実装を任せられていたとします。でも、急ぎの別作業が発生しました。今すぐやらないと大変なことになります。
最低限、2(可能なら3)まで終わらせていれば、それを呼び出す側で実装を進めている人に、「こういう風になっていて、まだ中身作ってないけどよろしく！」と伝えられるのです。

つまり、中身が作り終わっていなくても、とりあえず繋ぎこみが出来ている・動く状態になっているということです。（通常、全部できていると例外とかも追加されるはずなので、修正が発生しますが Mockによる単体テストを作る場合では、テストの実装も可能になります。

正直、一人で作業をしているのでメリットはあまりないのですが・・。
「冗長かな・・と思うクラスを後から作る必要がない」というのは、割と大きいかな…と思っています。つまり、DataTransferObject を作る必要なくて、ドメインモデル渡せば良い？とか、面倒な考えや形式がずれるということがなくなるのでは・・と期待しています。

今日はここまで

この記事を書いている時点で、サービスクラスを一切作っていないので・・。
今週はできる限り時間を作って、サービスクラスの作成を進めていきます。土曜日には、必要な機能の詳細を詰める作業、再度設計に戻れたら良いと思っています。

※大体、こういう時は上手くいった試しがありません。土曜日に記録投稿がなく、雑談だったらご察しください・・。

ここまで読んでいただき、ありがとうございます。

機会がありましたら、別の記事でお会いしましょう。

前へ　　　　次へ