Como construir uma estrutura de classe, quando os membros também são estruturados hierarquicamente?
Estou construindo um aplicativo Web PHP, que deve fornecer ao usuário a possibilidade de solicitar uma "instalação" / configuração de uma conexão (ConnectDirect ou File Transfer Gateway) entre ele e outra pessoa / organização.
(As especificações técnicas da implementação da conexão não são importantes - no aplicativo, são apenas as conexões como produto, que podem ser solicitadas e gerenciadas.)
A hierarquia de classes para sua camada de modelo deve representar a seguinte infraestrutura do mundo real:
temconexões, isso pode ser solicitado.Uma conexão pode ser uma conexão do IBM Connect: Direct ou uma conexão do IBM File Transfer Gateway.A CD conexão é direta de A (fonte) para B (alvo)A FTGW conexão consistefisicamente de duas conexões: A (origem) para o servidor FTGW e do servidor FTGW para B (destino) - maslogicamente (para o usuário que faz o pedido) também é uma conexão.(Além disso, há um caso de uma conexão FTGW, que usa o Connect: Direct como protocolo de conexão.)Cadaponto final é uma fonte ou um destino.Então, eu vejo os seguintes elementos lógicos:conexão lógica, conexão física, Função (fonte ealvo),Tipo de conexão, ordem, ponto final, tipo de ponto final (CD e FTGW).
A estrutura que tenho atualmente se parece com isso:
Mas existem alguns problemas com isso:
temduas árvores hierárquicas, onde cadaelemento de umconsiste contém elementos de um determinadosubconjunto do outro (cada conexão de CD consiste em pontos finais de CD; cada conexão FTGW consiste em dois pontos finais FTGW ou mais corretamente: cada conexão lógica FTGW consiste em duas conexões físicas FTGW - e cada uma delas consiste em um ponto final FTGW e no servidor FTGW como segundo ponto final).
Uma alternativa pode ser substituir o relacionamento betweetEndpoint
ePsysicalConnection
por dois relacionamentos:EndpointCD-PsysicalConnectionCD
eEndpointFTGW-PsysicalConnectionFTGW
.
Pró: Mais consistente; elimina a imprecisão lógica (ou talvez atéerro) da possibilidade falsa de criar todas as conexões (tipo) a partir de um par de quaisquer pontos de extremidade.Contra: Na verdade, o requisito de conter dois pontos de extremidade é uma característica de todas as conexões psíquicas - deste ponto de vista, o lugar certo para isso é o mais básicoPsysicalConnection
classe.
Cadaponto final pode serambos fonte e destino econtém não apenas as propriedades comuns do terminal, mas tambémpropriedades de origem e destino. Isso significa que, dependendo da função atual do terminal, algumas propriedades sãodesperdício. E isso também influenciará a estrutura do banco de dados (colunas, queas vezes tem que ser definido eas vezes tem que biNULL
)
Uma alternativa é estender a hierarquia ...
uma. ... por classes comoEndpointSource
eEndpoitTarget
herdando diretamente doEndpoint
e sendo herdado pelas classesEndpointCD
eEndpointFTGW
(isso significa: duas subárvores idênticas - sobEndpointSource
e abaixoEndpointTarget
);
b. ... por classes comoEndpointCDSource
eEndpointCDTarget
(herdando da classeEndpointCD
) eEndpointFTGWSource
eEndpointFTGWTarget
(herdando da classeEndpointFTGW
) sendo herdados cada uma das classes de terminais concretas CD ou FTGW (que significa: duas vezes duas subárvores idênticas);
c. ... por classes comoMyConcreteEndpoint***Source
eMyConcreteEndpoint***Target
herdar das classes concretas do terminal (que significa: todos osMyConcreteEndpoint
classe torna-se abstrata e obtém dois subtítulos -MyConcreteEndpoint***Source
eMyConcreteEndpoint***Target
, por exemplo.EndpointCDLinux
agora é abstrato e é herdado porEndpointCDLinuxSource
eEndpointCDLinuxTarget
)
Pró: elimina as propriedades de resíduos.Contra: Uma hierarquia de classes (mais) complexa.
Bem, é sobre arquitetura de software e deve (e é claro) ser minha decisão de design. Mas seria bom ouvir / ler alguns pensamentos de especialistas (ou não especialistas) sobre como lidar com esse caso. Quais são as maneiras adequadas de organizar os itens lógicos para uma infraestrutura como o que descrevi?