Estrutura de classes do lado do cliente no projeto UML

5

Eu e dois colegas da universidade estamos projetando um software CMS simples para um exame universitário usando a UML. Tal software só precisa lidar com o envio de um artigo, atribuindo um artigo para revisão, enviando uma revisão e marcando um artigo. Nossa solução espera uma arquitetura cliente-servidor de 3 camadas, com pequenos clientes solicitando serviços e um servidor respondendo a solicitações fazendo interface com um DBMS (dados persistentes) e um servidor SMTP (notificações por e-mail).

Estou num ponto em que não consigo decidir como estruturar minhas aulas do lado do cliente. Eu descobri um conjunto de classes limite representando serviços individuais e contendo métodos relacionados (autenticação, submissão de artigo, revisão de trabalhos ...) e uma única classe controle quais funções são solicitando conexão com o servidor ea criação de uma nova sessão, e contém os métodos para realmente enviar mensagens para o servidor.
Isso está de acordo com o princípio de responsabilidade única que determina que qualquer classe deve ser responsável por uma única funcionalidade do software: assim, Eu tenho uma classe para se inscrever / fazer login, uma para enviar um artigo, e assim por diante, e então a classe control que recebe solicitações de outras classes limite e envia mensagens para o servidor.

Por outro lado, outras pessoas me disseram que eu poderia até mesmo me livrar da classe controller do lado do cliente e dar métodos de classes diretamente enviar mensagens de solicitação para o servidor. Isso ainda parece legítimo para mim: as classes de limite só enviam pedidos de acordo com o serviço específico que deveriam fornecer ao usuário.

A pergunta é: está tendo uma classe control em meu aplicativo cliente útil, redundante ou errada? Como posso melhorar minha estrutura de classes?

    
por liggiorgio 20.11.2015 / 01:02
fonte

1 resposta

3

Question is: is having a control class in my client application useful, redundant, or wrong at all? How can I improve my classes structure?

É útil. Seu controlador, ctrClientManager, encapsula o sistema de mensagens no soquete; ele é responsável por criar o soquete, os fluxos de mensagens e outros encanamentos relacionados à mensagem. Cada classe de fronteira precisa dessa funcionalidade e levaria à duplicação de código se todas as classes de limite enviassem mensagens diretamente.
Melhora a manutenibilidade , porque se algo precisa ser alterado genericamente na comunicação entre cliente e servidor, você pode fazer isso em um lugar central (o controlador) ao invés de adaptar cada classe de fronteira .
Melhora a confiabilidade , porque a chance de haver um bug em uma parte central do código é menor do que a chance de haver um bug em uma das muitas cópias do mesmo código. / p>

A propósito, é recomendado aplicar o padrão MVC, onde cada visão (classe de fronteira) possui seu próprio controlador, para controlar a interação do usuário. Além disso, você deve ter o controlador de mensagens central, chamado ctrClientManager no seu exemplo.

    
por 21.11.2015 / 20:02
fonte

Tags