当成员也是分层结构时，如何构建类结构？

我正在构建一个 PHP Web 应用程序，它应该为用户提供订购他与另一个人/组织之间的（ConnectDirect 或文件传输网关）连接的“安装”/设置的可能性。

（连接实现的技术细节并不重要——在应用程序中，它只涉及作为产品的连接，可以订购和管理。）

其模型层的类层次结构应代表以下现实世界的基础设施：

• 有连接，可以订购。
• 连接可以是 IBM Connect:Direct 连接或 IBM File Transfer Gateway 连接。
• A CD连接直接来自 A (source) to B (target).
• A FTGW连接包括身体上的两个连接：A（源）到 FTGW 服务器以及从 FTGW 服务器到 B（目标）——但是逻辑上（对于订购用户）这也是一个连接。
• （还有一种 FTGW 连接的情况，它使用 Connect:Direct 作为协议。）
• Every endpoint是源或目标。

所以我看到以下逻辑元素：逻辑联系, 物理连接, role (source and target), 连接类型, order, endpoint, 端点类型（CD 和 FTGW）。

我目前的结构如下所示：

但它也存在一些问题：

1. 有两个层次结构树，其中每个element的一个consists包含特定的元素subset另一个（每个 CD 连接由 CD 端点组成；每个 FTGW 连接由两个 FTGW 端点组成，或更准确地说：每个 FTGW 逻辑连接由两个物理 FTGW 连接组成 - 每个 FTGW 连接由一个 FTGW 端点和 FTGW 服务器组成作为第二个端点）。

   另一种选择可能是替换之间的关系Endpoint and PsysicalConnection由两个关系：EndpointCD-PsysicalConnectionCD and EndpointFTGW-PsysicalConnectionFTGW.

Pro：更加一致；消除了逻辑上的不精确性（或者甚至可能mistake）从一对任意端点构建每个连接（类型）的伪造可能性。Contra：实际上，包含两个端点的要求是每个物理连接的一个特征 - 从这个角度来看，正确的位置是非常基本的PsysicalConnection class.

2. Every endpoint can be both源和目标以及contains不仅是公共端点属性，而且源和目标属性。这意味着，根据端点的当前角色，某些属性是waste。这也会影响数据库结构（列，有时必须设置并且有时必须双NULL).

   另一种选择是扩展层次结构......

   A。 ...按类EndpointSource and EndpoitTarget直接继承自Endpoint并被类继承EndpointCD and EndpointFTGW（这意味着：两个相同的子树 - 在EndpointSource及以下EndpointTarget);

   b. ...按类EndpointCDSource and EndpointCDTarget（继承自类EndpointCD) and EndpointFTGWSource and EndpointFTGWTarget（继承自类EndpointFTGW) 分别由具体的 CD 或 FTGW 端点类继承（这意味着：两个相同的子树两次）；

   C。 ...按类MyConcreteEndpoint***Source and MyConcreteEndpoint***Target从具体端点类继承（这意味着：每个MyConcreteEndpoint类变得抽象并获得两个子类——MyConcreteEndpoint***Source and MyConcreteEndpoint***Target, e.g. EndpointCDLinux现在是抽象的并被继承EndpointCDLinuxSource and EndpointCDLinuxTarget).

   Pro：消除废物特性。Contra：（更）复杂的类层次结构。

嗯，这是关于软件架构的，应该（当然将会）是我的设计决定。但很高兴听到/读到一些专家（或非专家）的想法，以及如何处理这种情况。组织像我所描述的基础设施的逻辑项的正确方法是什么？

也许我想太多了，但我建议您使用稍微不同的模型来反映您的业务逻辑。

以下可能完全是误解，但我会尝试一下。

So:

基于实际上任何连接是什么，这里有一个概念：

• 每个连接都是节点的集合，数据应通过这些节点传输才能到达目的地。
• 每个节点可以使用特定协议与下一个节点连接，该协议仅特定于两个特定节点之间的直接连接。
• 协议有其自己的源节点和目标节点共有的属性

基于此，我建议采用以下构建、管理和存储产品配置的模型：

Here:

• LogicalConnection 是对实际 Connection、Node 和 Protocol 类的构建组合的引用

• 连接包含一个节点的双链表，这些节点按数据流的顺序组成。即：第一个元素是源节点，第二个元素是其目标节点，依此类推。

• 具体节点包含特定于平台的配置、对目标 (*Node)、源节点 (*Node) 和具体协议 (*Protocol) 的引用

• Protocol 包含其针对源和目标的具体配置，Node 实例可以参考 Protocol 实例来提取所需的配置。

• 目标节点和源节点通过双链表结构“看到”彼此以及源-目标协议配置。

• Configurations\*ConfigBuilder 实现编排从 UI 接受数据并根据情况将其转换为连接、节点和协议的实际组合的过程。

• IBM\ConnectDirect\ 和 IBM\FTGW\ 命名空间包含协议和 *Node 的具体实现（例如 WindowsNode、UnixNode）

如果节点或协议仍然需要包含源和目标相关属性，并且其中一部分在某些配置中仍然可能为 NULL - 如果对未使用的列等有任何担忧，我建议对数据库使用 EAV 存储模型。

使用您所描述的建议模型连接可以表示如下：

Connection:IBM_CD {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      protocol:{//IBM.ConnectDirect.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//WindowsShareNode
      target:*nil,
      protocol:{
        //IBM.ConnectDirect.Protocol(same instance or null)
      }
      ..platform specific attributes..
    },
  ]
}

Connection:IBM_FTGW {
  nodes:[
    {//LinuxNode
      target:*nextElement,
      source:*nil,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      }
      ..platform specific attributes..
    },
    {//IntermediateServerLinuxNode
      target:*nextElement,
      source:*prevElement,
      protocol:{//IBM.FTGW.Protocol
        ..target attributes..
        ..source attributes..
      },
      ..platform specific attributes
    },
    {//WindowsShareNode
      target:*nil,
      source:*prevElement,
      protocol:*nil,
      ..platform specific attributes..
    }
  ]
}