Modelagem OO

Programação Arquitetura
#1

Caríssimos, estou aprendendo oo e tenho algumas dúvidas.

Por exemplo:

Tenho um objeto Conta com os métodos:

saca(Date data, Double valor, String Descricao, PlanoConta pconta)
deposita(Date data, Double valor, String Descricao, PlanoConta pconta).

A Conta tem os atributos Número, Agência, Banco.

Tem também um histórico de lançamentos com os seguintes atributos: Data, Descrição, Valor, Planodeconta

Exemplo de Plano de Contas:

Receitas
Vendas
Despesas
Custo Fixo
Custo Variável
…

A forma que implementei foi:

±------------------------------------------------------------------------------------------+
| Conta |
±------------------------------------------------------------------------------------------+
| - Numero |
| - Agencia |
| - Banco |
| - List<Lancamento> lancamentos |
±------------------------------------------------------------------------------------------+
| + void saca(Date data, Double valor, String Descricao, PlanoConta pconta) |
| + void deposita(Date data, Double valor, String Descricao, PlanoConta pconta) |
±------------------------------------------------------------------------------------------+

±--------------------+
| Lancamento |
±--------------------+
| - Data |
| - Valor |
| - Descricao |
| - PlanoConta |
±--------------------+

±------------------------------+
| PlanoConta |
±------------------------------+
| - Descricao |
| - List<PlanoConta> contas |
±------------------------------+

Dúvidas:
Nesse caso, Lançamento e PlanoConta seriam classes anêmicas, pois não tem métodos.
Em programação orientada a objetos, nós modelamos os objetos em termos do que eles fazem e não do que eles são (Bertrand Meyer ? Object Oriented Software Construction). Pensando assim as classes Lancamento e PlanoConta estariam ?erradas? (não sei se ?erradas? é o termo correto… rs) .
Como eu resolveria esse tipo de situação ?
PlanoConta e Lançamento só existem porque tenho que manter registro delas, gerar relatórios. (BD ou outra forma de persistência)
Estou modelando errado ? Alguma luz ?

#2

O livro do Bertrand Meyer é excelente. Você está muito bem encaminhado.

Minha sugestão é que vc separe suas classes em 2 tipos distintos. Classes de “entidades”, que só armazenam dados e que geralmente podem ser mapeados 1-1 com tabelas no seu banco de dados, e classes de “negócios”, que operam efetivamente sobre estes dados. Estas classes de “negócios” poderiam ser encaradas como classes que disponibilizam “serviços”, isto é, operações sobre estas classes de “entidades”.

Suas classes de “entidades” não teriam, geralmente, operações, e suas classes de “negócios” não manteriam, geralmente, ou por muito tempo, um “estado”.

Seria mais ou menos como separar as classes que são Modelo das classes que são Controle do seu MVC. A idéia aqui seria aproximar suas classes de entidades do acesso aos dados persistidos e manter a lógica de negócios numa camada separada.

Acho que seria um bom caminho.

[]

Léo

#3

Caríssimo, eu dei uma olhada nas suas classes; e claro, não tenho uma idéia total do que você está fazendo; mas eu faria de uma forma diferente, não que a sua forma esteja errada, mas eu faria assim:

Eu não criaria uma classe lançamentos específica, mas adotaria um método lançamento pertencente a classe conta. Eu teria um DB lançamentos para contas correntes, um DB lançamentos para Plano de Contas, mas poderia ser um só para todas as contas.

Class Conta_Geral

Propriedades

-numero
-saldo_debito
-saldo_credito
-saldo_conta
-natureza (débito ou crédito)

Metodos
-Somar_debitos
-Somar_creditos
-Totalizar
-Lancar (Date data, Double valor, String natureza, String documento, String Histórico, String Local)
- inserir (inserir contas novas, e novas especializações)
- deletar (deletar conta, que não foi sensibilizada no exercício)
- editar (mudar histórico, de forma mais apropriada etc)

Class Conta_Corrente Implementa Conta_Geral

Propriedades

- agencia
- banco
- saldo anterior
- saldo atual

Métodos
- Totalizar(Date data_atual) (semelhante ao saldo)
- Listar (Date data_inicio) (semelhante ao extrato)
- Abrir(String banco, String agencia, String numero)
- Encerrar(String banco, String agencia, String numero)
e por ai vai…

Class Conta_Poupanca Implementa Conta_Corrente

Propriedades
-variaçao (tipo de conta poupanca)
Métodos
- Totalizar_rendimentos(Date data_inicio,Data_final)

Class PConta implementa Conta_Geral
Propriedades

- descricao
- nivel    (as contas de planos de contas são totalizadas por níveis)
- nivel_proprietario  (uma maneira de amarrar  a conta ao seu grupo - exemplo  bancos conta movimento, é uma especialização do grupo ativo circulante, que é uma especialização de Ativo)
- formatacao (as contas de plano de contas obedecem uma formatação própria)

Metodos,

- totalizar_Nivel (fazer a soma dos elementos de mesmo nível, repassar saldo para niveis superiores, até esgotados todos os níveis)
- equalizar (totalizar contas do mesmo banco na conta específica do plano de contas para determinado banco - aqui nós poderiamos utilizar a Class Conta_Corrente e Class Conta_Poupanca)
         e por ai vai....



Espero ter ajudado.
#4

Valeu pessoal !

Vocês já ajudaram d+ !

Já deu pra entender muita coisa.

Abraços

#5

[quote=shikida]O livro do Bertrand Meyer é excelente. Você está muito bem encaminhado.

Minha sugestão é que vc separe suas classes em 2 tipos distintos. Classes de “entidades”, que só armazenam dados e que geralmente podem ser mapeados 1-1 com tabelas no seu banco de dados, e classes de “negócios”, que operam efetivamente sobre estes dados. Estas classes de “negócios” poderiam ser encaradas como classes que disponibilizam “serviços”, isto é, operações sobre estas classes de “entidades”.

Suas classes de “entidades” não teriam, geralmente, operações, e suas classes de “negócios” não manteriam, geralmente, ou por muito tempo, um “estado”.

Seria mais ou menos como separar as classes que são Modelo das classes que são Controle do seu MVC. A idéia aqui seria aproximar suas classes de entidades do acesso aos dados persistidos e manter a lógica de negócios numa camada separada.

Acho que seria um bom caminho.

[]

Léo[/quote]

Me desculpe mas sua sugestão vai levar a um programa procedural, onde as “classes-procedimento” operam sobre “classes-estrutura de dados”.

Se você ler o pattern MVC vai notar que o Modelo contém os dados E as regras de negócio, de forma coesa.

#6

recomendo fortemente você lê sobre DDD, creio que você estará apto a desenvolver software com qualidade, e com principios fundamentados em orientação a objetos. Esse tipo de programação onde negocio fica distante do dados, que são de fato manipulados pelos metodos de negocio, é uma tipo de programação inspirada em Enterprise Java Beans, visto que aplicação que usa tais artefatos geralmente é distribuida em camadas fisicas cujo nó’s de processamento estão em segmentos de rede diferentes.

Att
fidêncio.

#7

Também apoio a leitura sobre DDD. Seu código de negócio deve se assemelhar ao máximo das regras e dados do seu cliente, por isso recomendo DDD na maioria dos casos. Mesmo assim você pode ter uma aplicação enterprise robusta. As pessoas confundem muito MVC com arquitetura em camadas e com formas de design, como o DDD ou transaction script.

Se você me perguntasse onde eu não usei domain model (ou algo próximo a isso) foram em sistemas de integração. Muito xml pra cá e pra lá.

#8