Я создаю веб-приложение на PHP, которое должно предоставить пользователю возможность заказать «установку» / настройку (ConnectDirect или File Transfer Gateway) соединения между ним и другим человеком / организацией.

(Технические особенности реализации соединений не важны - в приложении речь идет только о соединениях как о продукте, которые можно заказать и управлять.)

Иерархия классов для ее модельного уровня должна представлять следующую реальную инфраструктуру:

Естьсвязи, что можно заказать.Соединение может быть соединением IBM Connect: Direct или соединением IBM File Transfer Gateway.A CD соединение прямое от А (источник) в B (цель).A FTGW соединение состоитфизически двух подключений: A (источник) к серверу FTGW и от сервера FTGW к B (цель) - нологически (для пользователя заказа) это также одно соединение.(Существует также случай соединения FTGW, в котором Connect: Direct используется в качестве протоколла.)каждыйконечная точка является либо источником, либо целью.

Итак, я вижу следующие логические элементы:логическая связь, физическая связь, роль (источник а такжецель),тип соединения, порядок, конечная точка, тип конечной точки (CD и FTGW).

Структура, которую я сейчас имею, выглядит так:

Но есть некоторые проблемы с этим:

Естьдва дерева иерархиигде каждыйэлемент одногосостоит содержит элементы определенногоподмножество другого (каждое соединение CD состоит из конечных точек CD; каждое соединение FTGW состоит из двух конечных точек FTGW, или, что более правильно: каждое логическое соединение FTGW состоит из двух физических соединений FTGW - и каждое из них состоит из конечной точки FTGW и сервера FTGW как вторая конечная точка).

Альтернативой может стать замена отношений междуEndpoint а такжеPsysicalConnection двумя отношениями:EndpointCD-PsysicalConnectionCD а такжеEndpointFTGW-PsysicalConnectionFTGW.

профессионал: Более последовательный; устраняет логическую неточность (или, может быть, дажеошибка) фиктивной возможности построить каждое соединение (тип) из пары любых конечных точек.против: На самом деле требование содержать две конечные точки является характеристикой каждой физической связи - с этой точки зрения правильное место для этого является самым основнымPsysicalConnection учебный класс.

каждыйконечная точка может бытьи то и другое источник и цель исодержит не только общие свойства конечной точки, но иисходные и целевые свойства, Это означает, что в зависимости от текущей роли конечной точки некоторые свойстваотходы, И это также будет влиять на структуру базы данных (столбцы, которыеиногда должны быть установлены ииногда должен биNULL).

Альтернативой является расширение иерархии ...

а. ... по классам вродеEndpointSource а такжеEndpoitTarget наследование непосредственно отEndpoint и наследуется классамиEndpointCD а такжеEndpointFTGW (это означает: два идентичных поддерева - подEndpointSource и подEndpointTarget);

б. ... по классам вродеEndpointCDSource а такжеEndpointCDTarget (наследование от классаEndpointCD) а такжеEndpointFTGWSource а такжеEndpointFTGWTarget (наследование от классаEndpointFTGW) наследуется каждым конкретным классом конечных точек CD или FTGW (что означает: два два идентичных поддерева);

с. ... по классам вродеMyConcreteEndpoint***Source а такжеMyConcreteEndpoint***Target наследование от конкретных классов конечных точек (это означает: каждыйMyConcreteEndpoint класс становится абстрактным и получает два подкласса -MyConcreteEndpoint***Source а такжеMyConcreteEndpoint***Targetнапример,EndpointCDLinux теперь является абстрактным и наследуетсяEndpointCDLinuxSource а такжеEndpointCDLinuxTarget).

профессионал: устраняет свойства отходов.против: (Более) сложная иерархия классов.

Ну, речь идет об архитектуре программного обеспечения и должна (и, конечно, будет) моим дизайнерским решением. Но было бы неплохо услышать / прочитать некоторые экспертные (или не экспертные) мысли о том, как справиться с таким делом. Как правильно организовать логические элементы для инфраструктуры, как я описал?