当成员也是分层结构时，如何构建类结构? [英] How to build a class structure, when members are also structured hierarchically?

问题描述

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

I'm building a PHP web application, that should provide to the user a possiblity to order an "installation"/setup of a (ConnectDirect or File Transfer Gateway) connection between him and another person/organization.

(连接实现的技术规范并不重要——在应用程序中，它只是关于作为产品的连接，可以订购和管理.)

(The technical specifica of the connection implementation are not important -- in the application it's only about the connections as product, that can be ordered and managed.)

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

The classes hierarchy for its model layer should represent following real-world infrastructure:

• 有连接，可以订购.
• 连接可以是 IBM Connect:Direct 连接或 IBM 文件传输网关连接.
• A CD 连接直接从 A(源)到 B(目标).
• 一个FTGW连接物理上由两个连接组成:A(源)到FTGW服务器和从FTGW服务器到B(目标)——但是逻辑上(对于订购用户)这也是一个连接.
• (还有一个 FTGW 连接的情况，它使用 Connect:Direct 作为 protokoll.)
• 每个端点要么是源，要么是目标.

• There are connections, that can be ordered.
• A connection can be an IBM Connect:Direct connnection or an IBM File Transfer Gateway connection.
• A CD connection is direct from A (source) to B (target).
• A FTGW connection consists physically of two connections: A (source) to the FTGW server and from the FTGW server to B (target) -- but logically (for the ordering user) it's also one connection.
• (There is additionally a case of an FTGW connection, that uses Connect:Direct as protokoll.)
• Every endpoint is either a source or a target.

所以我看到以下逻辑元素:逻辑连接、物理连接、角色(source和target)、连接类型、顺序、端点、端点类型(CD和FTGW).

So I see following logical elements: logical connection, physical connection, role (source and target), connection type, order, endpoint, endpoint type (CD and FTGW).

我目前的结构是这样的:

The structure I currently have looks like this:

但是它有一些问题:

1. 有两个层次树，其中一个包含的每个元素都包含特定子集的元素 另一个(每个 CD 连接由 CD 端点组成；每个 FTGW 连接由两个 FTGW 端点组成，或更准确地说:每个 FTGW 逻辑连接由两个物理 FTGW 连接组成——每个连接由一个 FTGW 端点和FTGW 服务器作为第二个端点).

1. There are two hierarchy trees, where each element of the one consists contains elements of a particular subset of the other (each CD connection consists of CD endpoints; each FTGW connection consists of two FTGW endpoints, or more correctly: each FTGW logical connection consists of two physical FTGW connections -- and each of them consists of an FTGW endpoint and the FTGW server as second endpoint).

另一种可能是将 Endpoint 和 PsysicalConnection 之间的关系替换为两个关系:EndpointCD-PsysicalConnectionCD 和 EndpointFTGW-PsysicalConnectionFTGW.

An alternative might be to replace the relationship betweet Endpoint and PsysicalConnection by two relationships: EndpointCD-PsysicalConnectionCD and EndpointFTGW-PsysicalConnectionFTGW.

Pro:更一致；消除了从任何端点对构建每个连接(类型)的伪造可能性的逻辑不精确性(甚至可能是错误).相反:实际上，包含两个端点的要求是每个心理连接的特征——从这个角度来看，正确的位置是非常基本的PsysicalConnection 类.

Pro: More consistent; eliminates the logical imprecision (or maybe even mistake) of the faked possibility to build every connection (type) from a pair of any endpoints. Contra: Actually the requirement to contain two endpoints is a characteristic of every psysical connection -- from this point of view the right place for this is the very basic PsysicalConnection class.

1. 每个端点都可以是源和目标，并且包含不仅是公共端点属性，而且源和目标属性.这意味着，根据端点的当前角色，某些属性是浪费.这也会影响数据库结构(列，有时必须设置，有时必须双NULL).

1. Every endpoint can be both source and target and contains not only the common endpoint properties, but also source and target properties. That means, dependent on the currnt role of the endpoint some properties are waste. And this will also be influence the database structure (columns, that sometimes have to be set and sometimes have to bi NULL).

另一种方法是扩展层次结构...

An alternative is to extend the hierarchy...

一个....通过EndpointSource 和EndpoitTarget 等类直接从Endpoint 继承并被EndpointCD 类继承，EndpointFTGW(即:两个相同的子树——在 EndpointSource 和 EndpointTarget 下)；

a. ...by classes like EndpointSource and EndpoitTarget inheriting directly from the Endpoint and being inherited by the classes EndpointCD and EndpointFTGW (that means: two identical subtrees -- under EndpointSource and under EndpointTarget);

B....通过EndpointCDSource 和EndpointCDTarget(继承自EndpointCD 类)和EndpointFTGWSource 和 等类EndpointFTGWTarget(继承自 EndpointFTGW 类)被具体的 CD 或 FTGW 端点类继承(这意味着:两次相同的子树)；

b. ...by classes like EndpointCDSource and EndpointCDTarget (inheriting from the class EndpointCD) and EndpointFTGWSource and EndpointFTGWTarget (inheriting from the class EndpointFTGW) being inherited each by the concrete CD or FTGW endpoint classes (that means: twice two identical subtrees);

c....通过诸如 MyConcreteEndpoint***Source 和 MyConcreteEndpoint***Target 之类的类继承自具体端点类(这意味着:每个 MyConcreteEndpoint类变得抽象并获得两个子类——MyConcreteEndpoint***Source 和 MyConcreteEndpoint***Target，例如 EndpointCDLinux 现在是抽象的并被继承通过 EndpointCDLinuxSource 和 EndpointCDLinuxTarget).

c. ...by classes like MyConcreteEndpoint***Source and MyConcreteEndpoint***Target inheriting from the concrete endpoint classes (that means: every MyConcreteEndpoint class becomes abstract and gets two sublesses -- MyConcreteEndpoint***Source and MyConcreteEndpoint***Target, e.g. EndpointCDLinux is now abstract and is inherited by EndpointCDLinuxSource and EndpointCDLinuxTarget).

Pro:消除浪费属性.相反:(更)复杂的类层次结构.

Pro: eliminates the waste properties. Contra: A (more) complex class hierarchy.

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

Well, it's about software architecture and should (and of course will) be my design decision. But it would be nice to hear/read some expert (or non-expert) thougts, how to handle such a case. What are proper ways to organize the logical items for an infrastructure like what I described?

推荐答案

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

Maybe I am overthinking, but I suggest for you to use slightly different model to reflect your business logic.

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

Following could be a total misunderstanding, but I'll give it a shot.

所以:

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

Basing on what in fact any connection is, here is a concept:

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

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

Basing on this I suggest following model of building, managing and storing a configuration of Product:

这里:

• LogicalConnection 是对实际连接、节点和协议类的构建组合的引用

• LogicalConnection is reference to built composition of actual Connection, Node and Protocol classes

Connection 包含节点的双向链接列表，这些节点按数据流的顺序组成.即:第一个元素是源节点，第二个元素是它的目标，依此类推.

Connection contains a double-linked list of Nodes which are composed in order as data flows. i.e.: 1st element is source node and 2nd is its target and so on.

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

Concrete Node contains platform specific configuration, reference to target (*Node), source node (*Node) and concrete protocol (*Protocol)

Protocol 包含其对源和目标的特定配置，Node 实例可以参考 Protocol 实例来提取所需的配置.

Protocol contains its specific configuration for source and target, Node instances may refer to Protocol instance to extract required configuration.

目标和源节点通过双链表结构看到"彼此和源-目标协议配置.

Target and Source Nodes "see" each-other and source-target protocol configuration via double-linked list structure.

Configurations\*ConfigBuilder 实现协调从 UI 接收数据并将其转换为实际组合的连接、节点和协议(视情况而定)的过程.

Configurations\*ConfigBuilder implementations orchestrate process of accepting data from UI and transforming it into actual composition of Connection, Node and Protocol depending on case.

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

IBM\ConnectDirect\ and IBM\FTGW\ namespaces contain concrete realizations for Protocol and *Node (e.g. WindowsNode, UnixNode)

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

If there still is a need for Node or Protocol to contain both source and target related attributes and part of them still could be NULL in some configurations - I suggest to use EAV storage model for DB if there is any concern about unused columns etc..

使用您在问题中描述的建议模型连接可以表示如下:

Using suggested model connections you described in question could be represented as following:

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..
    }
  ]
} 

这篇关于当成员也是分层结构时，如何构建类结构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！