ひがやすを技術ブログ

電通国際情報サービスのプログラマ

役割分担と疎結合

くーす

オブジェクト指向について意見を書くことは、特にデータと振る舞いを1つにすることが、常に正しいとは限らないなんて書くことは、私にとってものすごくリスクの高い&なんのメリットのないことです。
にもかかわらず、あえて書いているのは、正しくオブジェクト指向を実践しているように見えても、それが保守性の低下を招く場合もあるということを認識して欲しいということです。
さて本題に入ると、一般的な状況で、正しいクラスの粒度、責任範囲を明確にすることは困難なことだと思っています。人によって感覚が違っているからです。
http://d.hatena.ne.jp/kunit/20041219#1103438707で書かれている通りだと思います。
単一責任の原則も解の一つですが、責任の範囲が人によって解釈が異なるのは、仕方がないことなのかもしれません。
一般的な状況では確かにそうですが、業務アプリケーションに的を絞るとある程度規則性があります。

薄いサービス層とリッチなドメインオブジェクトパターン

  • プレゼンテーション層
    • プレゼンテーション層のモデル(DTO)
    • Action
  • サービス層
  • データアクセス層
  • ドメインオブジェクト

リッチな業務ロジック層とDTOパターン

  • プレゼンテーション層
    • プレゼンテーション層のモデル(DTO)
      • Entityを継承
    • Action
  • 業務ロジック層
  • データアクセス層
    • DAO
  • ドメインオブジェクト

薄いサービス層とリッチなドメインオブジェクトパターンは、サービス層で、DTOとEntityの相互変換をおこない業務ロジックはEntityに置く方法。
リッチな業務ロジック層とDTOパターンは、すべての層をDTOが流れていくパターンで、DAOがDTOを直接永続化します。業務ロジックは、業務ロジック層に置かれます。
工数は、リッチな業務ロジック層とDTOパターンのほうが少なくなります。DTOとEntityを相互変換する手間がかからないためです。
最も重要な保守性について考えてみましょう。
ある業務機能Aと業務機能Bがあり、お互いに直接関係はありませんが、同一のEntityDを使っているとします。
薄いサービス層とリッチなドメインオブジェクトパターンは、業務機能Aに仕様変更が入っても業務機能Bに仕様変更が入ってもEntityDを修正することになります。
リッチな業務ロジック層とDTOパターンは、業務機能Aに仕様変更が入った場合は、業務機能ALoigcの修正だけで済みます。業務機能Bに仕様変更が入った場合も同様です。
この違いは、疎結合性にあります。リッチな業務ロジック層とDTOパターンは疎結合なため、変更の影響範囲を極小化できるのです。
今度は、新たな業務機能Cが追加され、業務機能CもEntityDを使うことになったとします。
薄いサービス層とリッチなドメインオブジェクトパターンは、EntityDに業務機能C用のメソッドが追加されることになります。
リッチな業務ロジック層とDTOパターンは、業務機能CLogicが追加されるだけで、既存のクラスには影響がありません。
EntityDを使う新たな業務機能が追加されるたびにEntityDにメソッドを追加していくと、EntityDは次第に複雑になってきます。
リッチな業務ロジック層とDTOパターンの場合は、業務機能が増えても、複雑さが増すことはありません。疎結合だからです。
役割分担と疎結合性は、DI時代の最も重要なテーマなのです。