2

私たちのアプリケーションでは、メソッドはネストされたデータ構造を返すことがよくあります。それらを DTO として表し、1 つの DTO に他の DTO またはそのリストを含めることができます。問題のメソッドは、主に GUI に表示するものを提供します。

これまでのところ、「内部」DTO は通常のパブリック クラスのオブジェクトです。開発者は、これらの内部 DTO を他のさまざまな DTO クラスで再利用したくなります。これはコード再利用の歓迎すべきアプリケーションのように見えますが、緩やかに関連付けられたメソッドのみの間に不要な依存関係を作成します。

これを回避する 1 つの方法は、ネストがまったくなく、すべての属性が単純なスカラー型になるように DTO を「フラット化」することです。ただし、多くの場合、これは不自然に思えます。たとえば、外部 DTO と内部 DTO の間に 1:n の関係があり、そのような DTO をナビゲートするのがより面倒になる場合などです。

そこで、(外部 DTO のクラスの) 内部クラスの「内部」DTO インスタンスを作成できると考えました。これにより、コードの再利用が少なくなりますが、依存関係が軽減されます。

しかし、内部クラスを public にしない限り、外部から内部クラスのメソッドにアクセスできないことに気付きました (たとえば、そのような DTO を返すメソッド)。しかし、誰でもこの内部クラスのインスタンスを作成できます (ただし、それほど魅力的ではありません)。

したがって、基本的な質問は次のとおりです。

  • 完全に自己完結型の方法でネストされたデータ構造を表現する良い方法は何ですか?
4

2 に答える 2

0
  1. 内部クラスを使用できますが、それらにパブリック インターフェイスを実装させることができます。
  2. 私がお勧めする解決策の 1 つは、標準的なアプローチ (フィールドとしてのパブリック クラス) にとどまることですが、開発者がアスペクト ポリシーでそれらのクラスを使用することを禁止することです (これは私が見つけた短いチュートリアルです: http://www.jayway.com/2010/ 03/28/architectural-enforcement-with-aid-of-aspectj/ )。アスペクトを使用すると、次の 2 つのことができます。
    • クラスの使用を禁止する
    • 開発者に使用できない理由を伝える (ポリシー警告テキストを使用)
于 2013-08-01T09:45:51.177 に答える