From Procedural to OO

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

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:

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:

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:

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:

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?

Oi,

Se você consegue fazer os sitema com a mesma funcionaldiade com um console SQL apenas e só INSERT, DELETE, UPDATE e SELECT, realmente você pode não ter rum domínio que valha sequer ser modelado, mas eu duvido que seja tão simples assim.

Vou tratar o meu post pensando que sua aplicação não é tão simples assim (se for, porque usar Java em pimeiro lugar? Crie um script

).

Nesse caso específico, as regras de negócio deve estar espalhadas por outras partes do sistema, como interface.

Por exemplo, você pode ter uma regra na sua interface dizendo que o botão "alterar" só aparece para usuários com login de adminsitrador. Isso é uma regra de negócio (apenas administradores alteram chamados), e está implementada na interface, quando deveria estar no domínio. É esse tipo de informação que torna seu domínio rico, lembre-se: domínio é onde os problemas são processados

Reúna essas regras e tente visualizar quais delas pertencem à quais conceitos no seu domínio.

Shoes

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4679 Offline

Shoes, e como fazer essa lógica de negócio (atribuição de direitos) se integrar com a interface sem fazer merda?

Primeiro, pense que é uma validação. É como um campo int recebendo uma String.

O que fazemos com validação? A rigor, o objeto tem que ser responsável para garantir que vai receber um int, não uma String de caracteres.

Mas... você não vai usar um javaScriptzinho para garantir que alguém não digita por engano o login no lugar da idade? Você está duplicando a lógica para a comodidade.

Sim, você pode colocar uma verificação no botão, mas evite ao máximo duplicar código e faça apenas checagens, não processamento.

Shoes

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Shoes, num intendi, mas tá ok...

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Outra coisa que estava pensando é que getService terá de fazer acesso a DAO. Ou seja, as interfaces DAO farão parte da minha lógica de negócios, em vez de ser algo paralelo. Isso é ruim? Por quê?

Que tal parar de pensar em DAOs e comecar a usar Active Records?

http://www.martinfowler.com/eaaCatalog/activeRecord.html

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Eu entendi errado ou esse Active Record significa colocar o que o DAO faz no próprio objeto de negócio, tipo o próprio objeto cuida de sua persistência? Isso não piora o acoplamento com o banco? Como ficaria um getService(id, senha)?

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

O problema é quando se tem diversas formas de persistencia.
Em um tópico discutimos isso...

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4679 Offline

Não, não é problema. Basta usar interfaces e injeção de dependências.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Eu to com esses links pra ler, talvez ajude em algo:

http://www.guj.com.br/posts/list/0/20668.java

http://www.guj.com.br/posts/list/0/21616.java

http://www.guj.com.br/posts/list/0/21687.java

@PS: Ajude a mim

Virtual Machine Man Membro desde: 04/02/2005 13:49:20 Mensagens: 546 Offline

A questão é separar a lógica de negócio e a implementação de persistencia.
ex:

O problema é misturar o código de negócio com código de persistencia.

cv wrote:Que tal parar de pensar em DAOs e comecar a usar Active Records?

http://www.martinfowler.com/eaaCatalog/activeRecord.html

cv, pode dar um exemplo de como fazer isso em Java sem muita bronca? Outra coisa, se meus objetos de dominio possuem os dados, a logica de negocios e ainda resolvem a persistência, eles não estão um pouco sobrecarregados? Eu realmente estou muito interessado no Active Record, já que ele parece um bocado natural para mim, mas gostaria de ouvir opiniões sobre as implicações desse padrão.

LIPE wrote:Não, não é problema. Basta usar interfaces e injeção de dependências

LIPE, injetar as dependencias nos caras que no fim das contas farão a persistencia ou nos objetos de dominio?

valez...

GUJ Expert Membro desde: 12/03/2003 11:25:57 Mensagens: 4679 Offline

Falei sobre o objeto que vai se encarregar da persistência.
interface Persistent
class PersistentXML implements Persistent
class PersistentHibernate implements Persistent
pronto.

E quanto ao ActiveRecord, é ótimo para objetos mais simples. São apenas 4 métodos a mais.

This message was edited 1 time. Last update was at 09/06/2005 13:48:14

Não é melhor ter classes abstratas doque interfaces.
Assim vc reutiliza o código comum e pode separar as regras de negócio da persistencia.
ex:

Notícias, artigos e o maior fórum brasileiro sobre Java