Um design melhor?Mesmo objeto, diferentes estados possíveis

Question

Eu tenho um aplicativo muito simples que consiste em um site front-end ASP.NET, com um serviço WCF Windows fazendo o trabalho pesado da lógica de back-end.

O usuário tem uma página simples onde seleciona alguns parâmetros e aperta o botão 'enviar'.A página chama o serviço WCF e passa os parâmetros.O serviço instancia uma instância de uma classe 'Job', enviando os parâmetros para o construtor e, em seguida, chama um método 'Run()' que faz todo o trabalho de - inserir um registro de 'job' em um banco de dados com o nome do usuário, hora começou, etc...Faz uma solicitação a um fornecedor terceirizado, pega os dados, coloca-os no banco de dados, faz alguma outra lógica de negócios e marca o trabalho como concluído.

O usuário tem então uma segunda página simples onde ele pode pesquisar seu trabalho (uma caixa de combinação pesquisável classificada por data, exibindo vários campos relacionados a esse trabalho) e então exibir os dados correspondentes a esse trabalho na tela - (a maioria dos campos da tabela de empregos, por ex.hora de início, hora de conclusão, status, etc., exibidos como rótulos em um painel) e os dados reais que extraímos do fornecedor terceirizado (renderizados como uma grade, abaixo do painel).

Agora vamos à minha pergunta - então eu tenho uma classe Job que possui todos os campos mencionados acima, junto com seu método público Run() e construtores.Possui algumas funções privadas simples e vários membros privados que são interfaces para classes como IParser, IVendorConnection, IDataAccess - as classes que fazem todo o trabalho real descrito acima.a classe Job real e o método Run() não realizam muito trabalho real, praticamente apenas delegam trabalho para seus objetos compostos (proporcionam uma boa testabilidade, entre outras coisas).

Agora, esta classe Job tem 3 diferentes usos/estados possíveis.Seu principal uso é dentro do Service, para utilização da função Run() para literalmente executar um job.Ele também tem 2 outros usos - atuar como modelo para o painel que descrevi acima e atuar como modelo para a caixa de combinação que descrevi acima.A classe de trabalho possui 3 construtores públicos, cada um configurando-a para um dos 3 estados.Em todos os casos, cada 'estado' diferente se preocupa apenas com certos membros com os quais os outros 2 estados não se importam - em alguns casos, alguns dos membros são usados ​​em todos os 3 estados.O 'estado da caixa de combinação' é o mais simples - neste caso, quero apenas 3 campos somente leitura.No 'estado do painel', preocupo-me com 6 campos somente leitura.no estado 'trabalho', basicamente estou criando esses valores de campo à medida que o trabalho avança - e todos eles devem ser privados.

Estou apenas procurando uma maneira mais limpa de fazer isso.Se eu instanciar uma classe Job no estado A, eu saber que o acesso ao membro X não funcionará ou a chamada da função Y falhará.No entanto, ainda é um código compilável.

Tenho certeza de que outros já enfrentaram esse problema antes.Eu estava pensando em ter uma classe Job base marcada como MustInherit/abstract e depois ter 3 classes derivadas, uma para cada estado.Coloque os membros compartilhados na base e os específicos do estado nos derivados e use apenas as classes derivadas no meu código quando apropriado.Isso parece bastante simples para meus propósitos e resolve meu problema.Talvez eu também pudesse ter algum tipo de JobFactory...Acho que estou apenas procurando como outras pessoas resolveram isso, pois talvez eu não esteja pensando fora da caixa o suficiente...Já tive muitas classes sendo máquinas de estado antes em meus dias de desenvolvimento de jogos como hobby - mas isso era diferente, porque instâncias dessas classes podiam mudar de estado (por exemplo, uma classe 'Inimigo' poderia ter seu estado alterado de 'attack_mode' para 'waiting' ) No meu caso, não há mudança de estado - uma vez criado, um Job deve permanecer em seu estado e nunca tentar se comportar em um estado diferente.Rastrear o estado e lançar exceções se um método/membro for usado enquanto não estiver em um determinado estado parece frágil e muito trabalhoso.Alguma sugestão baseada em como você resolveu esse problema antes?E o que estou tentando fazer é um exagero?Se o trabalho começasse a ter cada vez mais estados diferentes, eu acho que não - mas talvez se ele conseguisse tantos estados diferentes, então eu precisaria pensar em dividi-lo em classes diferentes de qualquer maneira...Apenas procurando seus 2 centavos.

Answer 1

Sua ideia de criar um único trabalho de classe base com 3 classes derivadas soa exatamente como eu faria também.A criação de um JabFactory pode ajudar ainda mais neste design.Pode ser uma má prática criar um objeto onde partes do objeto não sejam usadas ou cujo uso seja ilegal em determinadas circunstâncias.Portanto, criar as classes derivadas apenas com as partes necessárias é claramente o melhor design.Não é um exagero.