Как построить структуру классов, когда члены также структурированы иерархически?
Я создаю веб-приложение на 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
).
профессионал: устраняет свойства отходов.против: (Более) сложная иерархия классов.
Ну, речь идет об архитектуре программного обеспечения и должна (и, конечно, будет) моим дизайнерским решением. Но было бы неплохо услышать / прочитать некоторые экспертные (или не экспертные) мысли о том, как справиться с таким делом. Как правильно организовать логические элементы для инфраструктуры, как я описал?