ダイコン時代のオブジェクト指向
従来のオブジェクト指向では、クラス・継承・多態性などを学んでも、
結局、実プロジェクトにどうやって活かしたらよいのか、
よくわからないというのが実情だったのではないでしょうか。
デザインパターンなども実際のコードに生かせるのは、
業務システムがターゲットだと皆無に近いのではないでしょうか。
これまでオブジェクト指向が生かされてきたのは、きっと
フレームワーク的な部分でしょう。
ダイコン時代のオブジェクト指向は、業務システムがターゲットです。
次の考えにもとづいています。
- 仕様と実装を分離する。
- 役割分担を明確にする。
- 最も結びつきの強いクラスに役割を担当させる。
1によって、並行開発が可能になり、納期の短縮が期待できます。
作業待ちも減るでしょう。
モックによるテストがしやすくなるので、自動テストのカバレッジが
増え品質も向上します。
UI層、サービス層、永続化層、エンティティ層に明確に役割分担することも
特徴的なところです。
従来のオブジェクト指向で最も難しいのはクラスの抽出ではないでしょうか。
現実世界を反映させたものではないことは間違いないところですが、
定石的なものが確立されていないので、四苦八苦していた部分だと思います。
ダイコン時代のオブジェクト指向では、クラスの抽出に明確な指針を
打ち出します。
最初にユースケースをロバストネス分析して、バウンダリ、コントロール、
エンティティを抽出します。
エンティティはER分析を経てエンティティ層のオブジェクトにマッピングされます。
コントロールは次のようなクラスにマッピングされます。
クラスの抽出は終わっているので、残りは、
- 各クラスに役割に応じた責務を割り当てる
- クラス間の依存関係を定義する
ことです。
役割が明確なので、責務を割り当てるのはそれほど難しくないでしょう。
クラス間の依存関係はダイコン定義に反映されます。
UI層のコントローラはサービス層との依存関係を持ち、
サービス層は永続化層と依存関係を持ち、
永続化層はO/Rマッピングのフレームワークと依存関係を持つというように
依存関係のパターンもあらかじめ決まってます。
ダイコン時代は、オブジェクト指向もシンプルかつ具体的な指針に基づいて
行うことができます。
