Implementacao Modelo objeto

Question

Ola pessoal, tenho uma questao de modelagem em uma classe, nao sei como prosseguir ,  ficarei grato da opiniao dos colegas pra me ajudar.

Tenho essa classe:

public class Ticket

{

public void CriarTicket()

{}

}

simples, porem o problema e na criacao do metodo CriarTicket,      tenho  3 tipos de usuarios na app, Comum, tecnico ou Admin, sendo que como usuario ele pode abrir ticket, mais o codigo nao  e o mesmo que o de tecnico.

Eu nao queria colocar um if ai no meio e fazer algo como

if(This.UsuarioAbriuChamado.Tipo == TipoUsuario.Comum)

//abre chamado como usuario

else if(this.UsuarioAbriuChamado.Tipo == TipoUsuario.Tecnico

//abre chamado como tecnico

pra saber se e usuario ou tecnico ou admin, isso e uma gambiarra.

Ja procurei sobre algum padrao, ou algo assim, estou estudando DDD, e por isso a solucao com ifs pra mim e nao e elegante.

Ja pensei em criar uma classe base com um metodo CriarChamado, e depois ciar 3 classes Usuario, Tecnico, Admi, e sobrescrever o metodo, porem a unica coisa que define se e Usuario ou Tecnico e um Tipo, basta um enum.

E tambem eu tenho outros metodos como por exemplo, O metodo ResponderChamado() ,  cai no mesmo principio do primeiro.

Porem a transferencia de chamado e feita somente por um tecnico ou Admin.

Enfim se algum dos colegas puderam me ajudar ficarei grato.

Answer 1

Ola Lourival,

Vc poderia criar uma classe abstrata ou interface (fica dificil sugerir o melhor sem conhecer mais detalhes do seu problema). Vou supor uma interface chamada ITicket, e um enum chamado TipoFuncionario:

    public enum TipoFuncionario
    {
        tecnico, admin
    }
 
    public interface ITicket
    {
        void CriarTicket();
    }
 
    public class TicketTecnico : ITicket
    {
        public void CriarTicket() { }
    }
    public class TicketAdmin : ITicket
    {
        public void CriarTicket() { }
    }

Note que foram criadas classes para tecnico e admin que implementam a interface. Poderia criar, entao, um Factory para criacao de ticket como o exemplo abaixo:

    public class TicketFactory
    {
        public static ITicket GetTicket(TipoFuncionario tipo)
        {
            if (tipo == TipoFuncionario.tecnico) return new TicketTecnico();
            if (tipo == TipoFuncionario.admin) return new TicketAdmin();
        }
    }

Desta forma, vc trabalhara com um objeto que foi criado de acordo com o tipo de funcioanrio, sendo que cada classe Ticket* tem uma implementacao diferente, conforme vc especificou. Dependendo de alguns fatores (por exemplo, se existem metodos que sao iguais para todos), vc poderia implementar uma classe abstrata ao inves da interface, mas o restante da logica de heranca / Factory continuariam a mesma.

Abracos, Daniel.

---

-- Se minha sugestão ajudou, por favor marque-a como útil; Se resolveu a questão, por favor marque-a como resposta. Contribua para melhorar o fórum! | [e-mail]

Answer 2

Opa camarada valew pela resposta, mais essa solucao como eu disse no meu post ja implementei, e nao adianta muito.

Criar 3 classes nao leva a muita coisa, tudo bem que o metodo criarticket para o tecnico e diferente de usuario, e de admin, na verdade tanto o metodo criarticket como reponderticket sao diferente.

No meu caso tenho uma so classe

Usuario, esse tem um enum tipo como vc colocou ai.  mais nao herda de nada.  pois o enum ja diz que tipo ele e.

public class Usuario : EntityBase: AgregateRoot

essa e minha heranca, se criar class TicketTecnico e TicketAdmin teria que ter Repositorio para isso tudo.. sendo que o que me interessa e so uma classe Usuario assim so teria Usuario que tem um repositorio.

no meu caso eu passaria assim

Ticket tcq = new Ticket();

tcq.UsuarioAbriuTicket = pega o user 

tq.abrir

deu pra entender ai camarada ??? vlw !!

Answer 3

Boa tarde Lourival Dutra, não entendi porque seria um gambiarra você acessar um atributo publico de um usuario.

Em algum lugar do código você vai ter que fazer essa verificação do tipo de usuário ou então você vai ter que pré-definir isso de alguma forma. Se a segunda opção for usada, ao adicionar um outro tipo de pessoa você vai ter que construir o tratamento para o novo tipo da mesma forma que você vai fazer usando os ifs.

Não vejo problema em fazer essa verificação, pois pense no problema no mundo real:
Um atendente vai abrir um ticket para você, ela precisaria saber qual o tipo de pessoa para abrir o ticket correto.  Abrangendo ainda mais, você vai abrir uma conta em um banco, o banco precisa saber qual o tipo de cliente você é, então é perguntado ao cliente ( qual o seu tipo de cliente? ), e ai com base no tipo de cliente que o usuario retorna o banco executa uma ação diferente. E o objetivo de classe é esse certo? Modelar na computação uma situação no mundo real.

Não gosto muito de certo padrões que descaracterizam isso de uma classe, por exemplo alguns que definem que uma classe vai ser apenas um "saco" com get e set de seus atributos.

Espero ter ajudado.