オブジェクト指向 アーキテクチャのメモ

以下クラス分けについて

作業上の視点

・独立してクラスから作れて外部からは内部を知る必要がないので早期から作れる。
・独立しているのでテストできる。

情報や実物からの視点

・メソッドから内部のデータを全て使う。高凝集度の単位。

・関心の単位。業務上の言葉で定義されている集まり。(ドメイン)
・ドメインオブジェクトの作り方の基本は値データをクラスでラッピング。

業務プログラムからの視点

・実際の物やデータの集まる単位、主に帳票や画面等。

・機能を洗い出してそのまま機能をクラス分けしないよう注意。機能はインターフェースなので、実装する物が必要。

変更や拡張性からの視点

・変更する理由が1つだけ。(単一責任)ただし、最初から理由が複数存在するか分からないのでリファクタリングしてクラス分け。

・何かを変更や拡張をしようとした際に影響がある単位。(変更や拡張がまったくないのであれば単位は大きくても問題ない)

・ポリモーフィズムの単位。(型のカプセル化)流動的要素をクラスにしてインターフェースでカプセル化する。(クライアントは実装を知る必要がない)

流動的要素から

・単一責務をもう少し具体的にすると、クラスに1つだけの流動的要素とする。流動的要素とは現実世界には複数の選択肢があり、それらが追加される可能性があること。

・流動的要素はメソッド(機能)ではなく主にデータで、特定の仕様や範囲、エンティティなど。分かりやすいのがテーブルデータゲートウェイ。

クラス分けについて、ここまで。

継承について

・継承の代わりにインターフェース。継承での再利用はフレームワーク等でのみ有効。継承は縦(isa)だったが、インターフェースで役割を分割して横の関係で再利用。

依存について

・クライアントが使わないメソッドに依存させない。(インターフェースを分離)役割を細かく分離することで役割が明確になる。

・newするとそこに依存する。インタフェースに依存させる。早い段階で変更がありそうな領域をクラス化しておく。

オブジェクト生成とオブジェクト利用はそれぞれ別のオブジェクトにする。(ファクトリー)

利用側はインスタンスをインターフェース型で受け取る。生成側はインターフェースを実装する。インターフェースの定義は上位レイヤーにて行う。(依存性逆転)

切り分け方について

インターフェース層、ロジック層などというレイヤー的な区切りよりも、変更や拡張の単位としてクラスを切り分ければ大丈夫。変更も拡張も確実に起きないのであれば、大きめなクラスにして、インターフェースにロジックを埋め込んでもほぼ問題は発生しない。

レイヤーアーキテクチャに関わること

環境によって用語や考え方が違う。共通しているのは依存関係をコントロールすること。だいたい、業務ロジックからの依存を禁止するか、上部から一方通行の依存のみとするか。

・永続化レイヤー
永続化のインターフェースをドメイン層に配置し実装を永続化層で行う。

テーブルとドメインオブジェクトの関係

・テーブルがそのままドメインオブジェクトで、テーブル操作に必要なメソッドは全て自分で持つという方法もある。ただし、業務上の関心の単位でドメインを作る場合、テーブルと同じだと粒度が大きすぎる。

・ドメインオブジェクトとテーブルをそれぞれ設計し、違いをマッパーオブジェクトが吸収する方法もある。何れにしてもドメインオブジェクトはテーブルに入るようなタイプのデータが集合しているということ。