[quote=sergiotaborda][quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s][quote=sergiotaborda][quote=Marcelo Magalh?s]Caro amigos,
Estou desenvolvendo um sistema contábil para utilizar na minha empresa e na de alguns colegas (sou técnico em contabilidade e também engenheiro de software, além de outras coisas...rsrsr). Com base nas nova lei 11.941/2009 e outras, montei um modelo de classe para a estrutura de contas e lançamentos contábeis (em anexo). Contudo estou com dúvidas no seguinte. Até o nivel que o modelo está feito é obrigatório e denominado pelos nomes que lá estão, contudo para "abaixo" deste nível, ou seja, as instâncias podem ser contas direto ou outros niveis.
Por exemplo. Pegando na estrutura Patrimonial->Ativo->AtivoCirculante podemos criar um outro níves tipo Conta Corrente e "abaixo" criar as inúmeras contas bancárias que uma empresa usa. Ou, simplesmente criar uma conta bancária direta, no caso de uma empresa ter somente uma conta. Isso é só um exemplo, não se atenham muito a "parte contábil" da coisa. A minha dúvida é como modelar esta possbilidade de criar contas ou outros níveis. Pensei em composite, mas no caso a composição de componentes não precisa ser "enxergada" como um componente, que é o que o padrão composite determina... estou certo? Qual a melhor forma de modelar isso?
[/quote]
A melhor forma é com uma estrutura de arvore , ou seja, Composite Pattern como vc bem identificou. A classe Account é uma classe composta por outras Accout. O Plano de Contas é a raiz de toda a arvore. As contas do ultimo nivel (aquelas onde realmente ha lançamentos ) são folhas da arvore e se ligam a outras classes ( por exemplo, Lançamento). As outras contas são ramos e apenas agrupam as contas filhas.
cuidado que este padrão não é muito SGDB friendly. pesquise sobre instruções de select em arvore do seu banco ou crie uma estrutura que permita consulta a arvore em qualquer nivel. [/quote]
Caro Sergio,
Poderia me dar um exemplo... no meu modelo onde ficaria a estrutura do composite? A classe componente (do padrão) especializaria as minha classe concretas, por exemplo AtivoCirculante? Ou meu modelo está errado?
Abraços.[/quote]
O seu modelo de ter uma classe para cada conta está errado. Vc só precisa de uma classe: Account
ela implementa o padrão composite. Ou seja ela tem os métodos addAccount() getChildrenAccounts(), etc…
o plano Patrimonial->Ativo->AtivoCirculante seria implementado assim
Account patrimonial = new Account();
patrimonial.setName("Patrimonial");
Account ativo = new Account();
ativo .setName("Ativo");
patrimonial.add(ativo);
Account ativoCirculante = new Account();
ativoCirculante.setName("Ativo Circulante ");
ativo.add(ativoCirculante);
Cada conta é uma instancia de Account e não uma subclass de Account.
[/quote]
Inicialemente, obrigado Sérgio. A fato de ter criado o primeiro nível com uma estrutura generalização/especialização foi que cada uma destas contas possui comportamentos específicos (funções contábeis). Poderia usar o Strategy, mas como combinar os dois padrões? Isso fiquei enrolado ai parti para a solução de criar a estrutura de árvore inicial vaté o ponto onde as contas possam a ter comportamentos iguais (como foi o caso do modelo). Qual seria a melhor saída? Juntar os padrões (composite + strategy) ou manter esta estrutura e "pendurar" o composite abaixo das contas já criadas.
Abraços.[/quote]
Elas não têm comportamentos diferentes. As funções contábeis são as mesmas : fazer lançamentos, obter saldo,etc…
O significado das contas que é diferente. Por exemplo, diferenciar entre o ativo e o passivo e calcular algumas coisa usando os dois.
digamos que quero saber a diferença entre o ativo e o passivo. Como eu obtenho isso no sistema ?
public Money diferenca(){
Account ativo = accountReposiory.getTypedAccount(AccountType.ATIVO);
Account passivo = accountReposiory.getTypedAccount(AccountType.PASSIVO);
Money balanceAtivo = balanceService.getBalance(ativo);
Money balancePassivo = balanceService.getBalance(passivo );
return balanceAtivo.minus(balancePassivo);
}
o segredo é o getTypedAccount()
Aqui vc tem duas opções. Ou quando vc cadastra a conta vc cadastra o tipo dela, ou vc faz um cadastro em que escolhe para cada
caracteristica contábil qual a conta que a representa. Ou vc cria um mecanismo de script (com o script engine) de forma que a amarração é feita via script e portanto mutável para cada cliente que usar esse sistema. Eu usaria a opção de cadastar contas para tipos, mas eu não conheço plano de contas o suficiente para saber se isso funciona para todos os casos.
[/quote]
Agora ficou mais claro… o classificador de tipos de contas… no exemplo anterior você não mencionou isso… ai fiquei em dúvida como iria distinguir contas de ativo de contas de passivo.
Quanto ao comportamento exitem sim diferenças… por exemplo quando você debita uma conta do ativo você está aumentando seu saldo devedor… e uma conta do passivo funciona ao contrário, quando aumenta seu saldo você deve creditar na conta, ou seja, existe sim um comportamento diferente entre as contas (no ponto de vista contábil).
Abraços.