From Procedural to OO

Eu e meu colega fizemos uma aplicação simples com essas funcionalidades:

1. Solicitar chamado técnico/ serviço (assunto selecionado de uma lista)
2. Consultar um chamado aberto por um atendente

Fizemos num estilo procedural como o Shoes fala, e como o Fernando Lozano me induziu:

Classes de dados:

• ServiceRequest (funcionalidade 1) - representa os campos da requisição de serviço
• Service (funcionalidade 2) - campos de um serviço já aberto
• HistoryItem (funcionalidade 2) - cada serviço possui um histórico com itens que indicam o andamento do serviço

Classes de lógica

• DateConverter (converte datas Java para outro formato usado no banco - não é o tipo “data” nativo do banco, é um float)
• DataAccess com só três métodos:

public Service getService(int code, int password) throws DataAccessException...
public void saveServiceRequest(ServiceRequest serviceRequest) throws DataAccessException...
public List getAllSubjects() throws DataAccessException...

Ou seja:

1. Obter um serviço (func. 2 - consulta)
2. Salvar uma requisição de serviço (func. 1 - solicitação)
3. Pegar a lista de assuntos possíveis numa solicitação (func. 1 - o assunto da solicitação é escolhido de uma lista)

Não estou deprimido por causa disso (o sistema é muito pequeno), mas depois de discutir sobre o assunto, só por curiosidade

ou exercício dos conceitos, fico pensando o seguinte:

Se eu for “oozar” o projeto puxa onde eu colocaria essses métodos, como mesclaria com as classes de dados??

Minha idéia no momento é a seguinte:

método 1) Quem provê um serviço? A empresa, os técnicos, o sistema… Mas pra que criar uma classe ServiceProvider, Technician, System, HelpDesk etc. só pra colocar esse método?? Os serviços simplesmente existem e têm uma etiquetinha de identificação. O usuário, de posse do número dessa etiqueta (como ele o obtém não é escopo do nosso sistema), simplesmente vai no meio dos objetos e “pega” o Service de seu interesse. Conclusão: este método eu moveria para a classe
service, como um metodo estático:

Service service = Service.getService(123, 601);

método 2) “Salvar” refere-se à persistência, que não é lógica de negócios, é um mecanismo de auxílio. Ou seja, quando o usuário quer fazer uma nova solicitação de serviço, ele simplesmente a faz, ele a cria. Conclusão: este método vai para um DAO (ignorem a persistência), assim, na lógica de negócios, uma nova solicitação se faria assim:

ServiceRequest serviceRequest = new ServiceRequest();
// preenche os dados do serviceRequest 
// Aqui acontece uma mágica, o objeto é salvo pro disco automaticamente (hoje em dia não é verdade)

método 3) Quem provê um assunto? Imagino ser parecido com o método 1, por isso os assuntos são limitados, mas existem por si só. Logo o usuário, durante uma requisição pegaria um assunto. O problema é que não queria criar uma classe Subject (e de fato não há) por que um assunto nada mais é que uma String, e um conjunto de assuntos, um List. Pensando que um assunto é uma característica de um ServiceRequest (assunto da solicitação de serviço), eu colocaria esse método na classe ServiceRequest como static:

List subjects = ServiceRequest.getAllPossibleSubjects();

No caso do DateConverter também não faz parte da lógica de negócios, mas de um DAO. Por isso seria movido para lá.

Ou seja, remodelando o sistema assim teríamos as seguintes classes:

• Service
• ServiceRequest
• atualmente, um DAO (não é lógica de negócios)

Sugestões e opiniões?