如何建立一个类结构，当成员也分层结构？ [英] 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.

（连接实现的技术的specifica并不重要 - 在应用程序中，这只是关于连接的产品，也可以订购和管理。）

(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.)

中的类层次结构的模型层应该重新下真实世界的基础设施present：

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

• 还有的连接的，可以订购。


• 的连接可以是IBM连接：直接连接系统，或IBM文件传输网关连接


• A CD 的连接是从直接的（源的）到B（的目标的）。


• A FTGW 的连接由物理的两个连接：A（源）到FTGW服务器和从服务器FTGW到B（目标） - 但是的逻辑的（对于订单用户），这也是一个连接。


• （有另外一个FTGW连接，使用连接的情况：直接为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.

所以我看到以下逻辑元素：逻辑连接的物理连接的角色的（源和目标的）的连接类型的订单的端点的端点类型的（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).

另一种可能是由两个关系来代替betweet 端点和 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.

临：更一致;消除了逻辑IM precision（或者甚至的错误的）的可能性伪造建设从一对任何端点的每一个连接（类型）。 魂斗罗：其实包含两个端点的要求是每个psysical连接的特性 - 从这个角度来看这个正确的地方是非常基本的 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.

每端点能两个源和目标和包含不仅是公共端点属性，而且还源和目标属性即可。这意味着，依赖于端点某些属性的废料的currnt作用。而这也将是影响数据库结构（列，即有时的必须设置和有时的有到BI 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 直接从端点继承和类被继承 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);

乙。 ...由像 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);

℃。 ...由像 MyConcreteEndpoint类***源和 MyConcreteEndpoint ***目标从具体的端点类继承（这意味着：每一个 MyConcreteEndpoint 类成为抽象的，得到两张sublesses - MyConcreteEndpoint ***源和 MyConcreteEndpoint ***目标，例如 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).

临：消除浪费属性。 魂斗罗：A（更多）复杂的类层次

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

嗯，这是关于软件架构和应（当然会）是我的设计决策。但它会很高兴听到/读一些专家（或非专家）thougts，如何处理这种情况。什么是正确的方式来组织的逻辑物品如我所描述的基础设施？

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

混凝土节点包含平台的具体配置，参考目标（*节点），源节点（*节点）和具体的协议（*协议）

Concrete Node contains platform specific configuration, reference to target (*Node), source node (*Node) and concrete protocol (*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.

配置\\ * 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 \\命名空间包含协议和具体的实现*节点（例如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..

使用您在问题中所述建议的模式连接可以重新psented如下$ P $：

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屋！