php - メンバーも階層的に構造化されている場合、クラス構造を構築する方法は?

Question

私はPHP Webアプリケーションを構築しています。これは、ユーザーと別の人/組織との間の(ConnectDirectまたはファイル転送ゲートウェイ)接続の「インストール」/セットアップを注文する可能性をユーザーに提供する必要があります。

(接続実装の技術仕様は重要ではありません。アプリケーションでは、注文および管理できる製品としての接続のみが重要です。)

そのモデル レイヤーのクラス階層は、次の現実世界のインフラストラクチャを表す必要があります。

• 注文できる接続があります。
• 接続は、IBM Connect:Direct 接続または IBM File Transfer Gateway 接続のいずれかです。
• CD接続は、 A (ソース) から B (ターゲット) への直接接続です。
• FTGW接続は、物理的に 2つの接続で構成されます。FTGW サーバーへの A (ソース) と FTGW サーバーから B (ターゲット) への接続ですが、論理的には (注文ユーザーにとって) 1 つの接続でもあります。
• (Connect:Direct をプロトコルとして使用する FTGW 接続の場合もあります。)
• すべてのエンドポイントは、ソースまたはターゲットのいずれかです。

したがって、次の論理要素が表示されます: logical connection、physical connection、role ( sourceおよびtarget )、connection type、order、endpoint、endpoint type (CD および FTGW)。

私が現在持っている構造は次のようになります。

しかし、それにはいくつかの問題があります:

1. 2 つの階層ツリーがあり、一方の要素には他方の特定のサブセットの要素が含まれます (各 CD 接続は CD エンドポイントで構成され、各 FTGW 接続は 2 つの FTGW エンドポイントで構成されます。より正確には、各 FTGW 論理接続は2 つの物理的な FTGW 接続 -- それぞれが FTGW エンドポイントと 2 番目のエンドポイントとしての FTGW サーバーで構成されます)。

   別の方法として、関係 betweetEndpointとPsysicalConnectionを 2 つの関係 (EndpointCD-PsysicalConnectionCDと) に置き換えることもできますEndpointFTGW-PsysicalConnectionFTGW。

長所: より一貫性があります。任意のエンドポイントのペアからすべての接続 (タイプ) を構築する偽の可能性の論理的な不正確さ (またはおそらく間違い) を排除します。反対: 実際には、2 つのエンドポイントを含むという要件は、すべての物理的な接続の特徴です。この観点からすると、これに適した場所は非常に基本的なPsysicalConnectionクラスです。

2. すべてのエンドポイントはソースとターゲットの両方になることができ、共通のエンドポイント プロパティだけでなく、ソース プロパティとターゲット プロパティも含まれます。つまり、エンドポイントの現在の役割に応じて、一部のプロパティが Waste になります。また、これはデータベース構造にも影響を与えます (列、時には設定する必要があり、時にはbi にする必要があります)。NULL

   別の方法は、階層を拡張することです...

   a. ... のようなクラスによってEndpointSource、EndpoitTargetから直接Endpoint継承され、クラスによって継承されますEndpointCD(EndpointFTGWつまり、2 つの同一のサブツリー -- の下EndpointSourceと下EndpointTarget);

   b. ... and ( class から継承) およびEndpointCDSourceand ( class から継承) のようなクラスによって、具体的な CD または FTGW エンドポイント クラスによってそれぞれ継承されます (つまり、2 つの同一のサブツリーが 2 倍になることを意味します)。EndpointCDTargetEndpointCDEndpointFTGWSourceEndpointFTGWTargetEndpointFTGW

   c. ...具象エンドポイントクラスと同様のクラスMyConcreteEndpoint***SourceとMyConcreteEndpoint***Target継承するクラスによって（つまり、すべてMyConcreteEndpointのクラスが抽象になり、2つのサブレスを取得します-たとえば、MyConcreteEndpoint***Sourceandは抽象になり、 and に継承されます）。MyConcreteEndpoint***TargetEndpointCDLinuxEndpointCDLinuxSourceEndpointCDLinuxTarget

   長所: 廃棄物の特性を排除します。Contra : (より) 複雑なクラス階層。

まあ、それはソフトウェア アーキテクチャに関するものであり、私の設計上の決定であるべきです (もちろんそうなるでしょう)。しかし、専門家（または専門家ではない）の考え、そのようなケースをどのように処理するかを聞いたり読んだりするといいでしょう。私が説明したようなインフラストラクチャの論理アイテムを整理する適切な方法は何ですか?