はじめに
最近、「現場で役立つシステム設計の原則」を読んでいるので、本書の中で自分が疑問に感じたポイントをQ&A形式で振り返ってみたいと思います。
この記事では、各セクションの簡単な説明の後に、[Q]で疑問に感じたこと、[A]で調べてわかったこと、そして[NOTE]で覚えておきたいことをまとめています。
なお、サンプルコードにJavaを使用していますが、言語を問わず広く有効な設計手法なので、他言語でも応用できる内容になっています。
第7～8章については、すでに別の記事にまとめているので、こちらもぜひご覧ください！
それでは、第9〜10章を振り返りながら、一緒に「システム設計」について学んでいきましょう！
業務ロジックに焦点を当てて開発を進める
業務アプリケーションの複雑さは、対象とする業務の構造や決め事の複雑さに対応します。
ソフトウェア全体をわかりやすい構造で整理する基本は、複雑な業務ロジックをドメインモデルに集約し、整理することです。
そのためには、業務を理解し整理するための「分析」と、ソフトウェアとしての実現方法を考える「設計」を、同じ人間／チームが一貫して担当することが効果的です。
オブジェクト指向の狙いである変更容易性を実現する開発では、次の2点に焦点を当てることがマネジメントの軸になります。
- ドメインモデルに業務ロジックを集めて整理する活動
- 要求の分析とソフトウェアの設計は同じ人間／チームが担当する体制
[NOTE]
オブジェクト指向の開発では、分析と設計を同じ技術者が担当します。
分析クラスがそのまま設計クラスになり、実装されたプログラムのクラス名やメソッド名が業務の用語や概念と一致するようになります。
そうなると、ソフトウェア開発におけるドキュメントの位置づけが大きく変わります。
まず決定事項の多くは、開発の早い段階からソースコードに記録されます。
ほかの形式で二重に記録する必要はありません。
伝達手段としてのドキュメントの必要性もほとんどなくなります。
分析する人間が設計し、設計内容をソースコードとして直接記録するのであれば、ドキュメントを使って伝達する必要はありません。
進捗の管理も、ソースコードを管理すればよいわけです。
ドメインモデルのソースコードを見れば、分析がどの程度進んでいるかを適切に判断できます。
実際のコードで設計の違いを知る
オブジェクト指向が威力を発揮するのは、ソフトウェアを変更するときです。
ソフトウェアの規模が膨らみ、最初の開発から何年も経過し、修正や拡張が繰り返され、コードが入り組んだ変更がやっかいなプログラム......。
そういうプログラムこそ、オブジェクト指向の設計の考え方とやり方を学ぶ、絶好の教材です。
変更が大変なプログラムは、たいていメソッドが長くクラスが巨大です。
オブジェクト指向を学ぶ第一歩は、こういう変更がやりにくいコードを、短いメソッドや小さなクラスにうまく分解してみることです。
[NOTE]
実際のコードを書き換えながら、オブジェクト指向のやり方と考え方を学べる練習方法があります。
『ThoughtWorksアンソロジー』という参考書の第5章で「オブジェクト指向エクササイズ」として紹介されている次の9つのルールです。
- ルール1：1つのメソッドにつきインデントは1段階までにすること
- ルール2：else句を使用しないこと
- ルール3：すべてのプリミティブ型と文字列型をラップすること
- ルール4：1行につきドットは1つまでにすること
- ルール5：名前を省略しないこと
- ルール6：すべてのエンティティを小さくすること
- ルール7：1つのクラスにつきインスタンス変数は2つまでにすること
- ルール8：ファーストクラスコレクションを使用すること
- ルール9：getter、setter、プロパティを使用しないこと
ルールに従ったそういう新しい書き方を何度か繰り返していると、いつのまにか、意識せずにオブジェクト指向らしい書き方ができるようになっているはずです。
おわりに
今回は、「現場で役立つシステム設計の原則」の第9〜10章を題材に、自分が疑問に感じたポイントを紹介しました。
設計の原則は「読む」だけでなく、手を動かして確かめてこそ身につきますよね！
今後も読み進めながら、気づきがあればこうした形でまとめていきたいと思います！