前回 の続きです
意図の明白なインターフェース
しなやかな設計のパターンその１は「意図の明白なインターフェース」。
名前が大事
ビジネスのルールを明示的にモデル化することは、第９章 暗黙的な概念を明示的にするで見てきたように、深いモデルへの手がかりとなります。
ただし、明示された概念の名前がわかりずらいと、結局実装を読まなくてはいけない状況になってしまい本末転倒です。
意図の明白なインターフェース
なので、モデルに対する必要な概念は、実装の中身を見なくても良いように、オブジェクトを使用するための正しい名前になっている必要があります。。
モデルはその設計の意図が明らかになるように、型名・メソッド名・引数名が揃っていなければいけません。
これらが、すべて組み合わさって意図の明白なインターフェースが形成されます。
メソッド名の変更[リファクタリング]
MartinFowlerもリファクタリングの「メソッド名の変更」パターンにて、こう述べています。
メソッドにはその意図を伝えられるような名前をつけるべきです。
意図を示す名前[実装パターン]
KentBeckも実装パターンにて、「意図を示す名前」として以下のように述べています。
メソッド名は意図を伝達し、他の情報は他の方法で伝えるようにしよう
言うは易し行うは難し
「良い名前をつける」というのは色々な本に書いてありますし、言われなくてもわかるよと思う人も多いかと。
ただ、それができていますか？と聞かれると「う〜ん」と唸る人も多いのでは。自分も含めて。
言うは易し行うは難しという言葉がこれほど合うパターンはないでしょうね。
ドメイン駆動設計的テストファースト
では、実際どうすれば意図の明白なインターフェースを設計できるか。
それは、振る舞いを実装する前にテストを書いて実際にモデルを使用することです。
実装を書く前にテストを書くことで、モデルを利用する側の視点が得られ、意図の明白なインターフェースが理解できるようになります。
ん〜。これやってなかったな。。。こういう観点でテストを書くと、また違った視点を得られますね。
とりあえず、テスト駆動開発を読みましょう。
レビューを受けること
書籍にはなかったですが、第三者のレビューを受けることも役に立ちそう。
実装の詳細をレビューすることにはあまり意味はありません。テスト書けばいい話ですからね。
メソッド名から、変数名から、引数から、モデルの意図が理解できるか。この観点でレビューをしてもらえば良いのかと思います。
最近流行りの「モブプログラミング」やXPの「ペアプロ」も多くの利点があって、会社でも活用しているプラクティスなのですが、全員が「作る側」になってしまって、「使う側」の観点で見ることができるのかな？と今回これ読んで思ったりしました。
モブプロに参加していなかった人からのレビューもプラスで実施するといいかもしれませんね。