| Autor |
Mensagem |
|
|
Há algum tempo li uma discussão onde o Linus Torvalds defendia que C++ não é uma boa escolha para o Kernel de um SO. Segundo ele, bem que tentaram usar C++ no Kernel do Linux, isso lá pelos idos de 1992, mas acabaram vendo que não era uma boa.
Embora ele não seja o dono da verdade, sem dúvida é uma opinião de peso. Mas infelizmente não estou encontrando o endereço mais 
|
 |
|
|
Emerson Macedo,
Eu já havia lido essa thread, foi uma discussão realmente boa
Giulliano,
Isso implica que o quarto tenha que acessar o repositório, para poder consultar as reservas. Correto?
Não há nenhum problema nisso?
|
|
|
|
Vejamos....
Em um sistema de hoteis, não pode haver mais de uma conta para o mesmo quarto no mesmo período
|
|
|
|
Leonardo3001,
Eu diria que para cada produto que entra ou sai do estoque da empresa, isso deve ser registrado de forma que eu sempre possa saber a quantidade em estoque de cada produto em um determinado momento
|
|
|
|
|
Ok... Então quais classes devem validar estas regras?
|
|
|
|
Ontem eu estava assistindo a um vídeo de uma palestra do Giovanni Bassi sobre DDD (http://unplugged.giggio.net/unplugged/post/Video-sobre-Domain-Driven-Design.aspx), em geral achei muito boa mas não consegui engolir uma coisa:
O Giovanni diz que repositórios não podem ter regras de negócio.
Mas o repositório não faz parte da camada de negócios? Nesse caso, por que não poderia ter regras de negócio?
Segundo o que tenho lido, a diferença entre um repositório e um DAO é justamente essa: O DAO é infra-estrutura, e por isso não pode ter regras de negócio. Já o repositório faz parte do negócio, por isso pode executar validações e tudo mais
|
|
|
|
Até hoje, sempre implementei controle de estoque da seguinte maneira (de uma forma simplificada):
Tenho as tabelas de produtos, entradas, vendas, e uma tabela contando todo o histórico de movimentação do estoque. Esta tabela de movimentação tem um campo para o id do produto, um campo para dizer se a movimentação foi uma entrada ou saída, um campo para a quantidade e outro para o saldo.
Quando entra um produto, uma trigger no banco insere um registro na tabela de movimentações referente à entrada, e na tabela de vendas uma trigger similar.
Na tabela de movimentação, tenho uma trigger que atualiza toda a tabela sempre que um novo registro é inserido. Ou seja, quando registro uma movimentação de estoque, pego todos os registros já existentes referentes ao mesmo produto, com data maior que a data do registro sendo inserido, e atualizo o saldo neles.
Pois bem... Segundo o DDD, qual seria a forma mais adequada de implementar isso?
Eu teria um repositório para movimentações de estoque? E aí ao gravar um registro, esse mesmo repositorio ficaria encarregado de carregar as outras movimentações, atualizar o saldo nelas e gravar novamente?
|
|
|
|
Um exemplo onde eu acho que o singleton se encaixa bem (quem quiser discordar fique à vontade, eu ainda tenho mt o que aprender em orientação a objetos)
Em Delphi, trabalho em um sistema que precisa se comunicar com impressoras fiscais (ECF).
Então tenho uma interface chamada IEcf, e várias implementações para cada fabricante/modelo de ecf (TEcfDaruma, TEcfBematech, etc).
Seja lá qual for a impressora que o cliente usar, o sistema vai instanciar a classe correspondente e usará essa instancia durante toda a execução do sistema.
Mas todos os métodos que precisam se comunicar com a impressora recebem o IEcf via parâmetro do método ou no construtor da classe. Eu não tenho uma variável ou função global onde todo mundo vai quando precisa da impressora.
|
|
|
|
Acho que o grande problema do Singleton é esse famoso ".getInstance()".
Quando se faz algo assim:
Sua classe fica com um acoplamento muito grande com MeuSingleton. Agora aplica testes unitários nisso ae: Se um teste alterar o estado do seu singleton, outro teste vai enxergar isso. Resultado: Um teste depende do outro. Pra resolver, no mínimo vais ter que fazer algumas gambiarras.
Quando uso singletons, eu recebo a instancia dele via injeção de dependencias: Como parametro no próprio método ou no construtor da classe. E então deixo o container de DI (Em Delphi fui obrigado a implementar o meu) gerenciar a instancia do singleton.
Postei no meu blog um pouco das ideias que tenho sobre isso: http://blog.magnomachado.com.br/?p=8
|
|
|
|
Bom, aproveitando que já reviveram o tópico com a carta mágica...
Imaginem uma tela de consulta onde o usuário pode combinar algumas condições disponíveis e montar um filtro: Ex: Consultar clientes ativos na cidade X
Essa consulta deve ser passada para um DAO? E como lidar com esse filtro dinamico?
|
|
|
|
Mas generics e annotations são recursos do java 5 para cima...
Você usa maven para build? Faz um tempinho que não uso, mas se bem me lembro, há um parametro que você coloca no pom.xml que diz qual a versão do java será considerada na hora de compilar
|
|
|
|
De cabeça não me lembro mais rsrs 
Mas hoje à noite quando chegar em casa eu olho e te falo
|
|
|
|
Acabei de usar injeção de dependencia ali, e sem nenhum framework. Mais especificamente, isso é injeção pelo construtor. Existe tambem injeção via setter, e um outro tipo que não me lembro.
Eu desenvolvi um framework de DI para Delphi (http://www.emballo-di.com) que trabalha apenas com injeção via construtor. Tudo que ele faz é resolver os parametros do construtor e invoca-lo via reflexão.
Eu havia implementado um método de injeção que ele enumerava todos os atributos da classe e injetava em cada um, sem precisar usar nem um setter, mas posteriormente eu removi isso pois vi que não era muito bom injetar dessa forma
|
|
|
|
Fiquei curioso, no entanto, quando você falou "facilmente testar"
Quando disse isso, estava me referindo a testar classes que dependem das interfaces que fazem a abstração dos dispositivos em questão. Isso eu já faço, e sinceramente não é nem um pouco dificil.
Eu não estava me referindo aos testes das classes concretas que implementam a comunicação com os equipamentos externos, me desculpe caso eu tenha me expressado mal.
Obrigado pelas informações, vou pesquisar a respeito.
Ao Tchello, obrigado pela indicação do site
|
|
|
|
Qual a maneira mais apropriada de testar classes que utilizam equipamentos externos? Por exemplo, uma impressora fiscal.
Ex: Eu posso ter uma interface chamada ECF para abstrair as impressoras, e então usar injeção de dependencias para colocar implementações dessa interface (Ex: Classe ECFDaruma, ECFBematech, etc) nas classes que precisam lidar com ecf. Assim, posso facilmente testar tais classes no DUnit* sem precisar ter um ECF real, bastando usar um mock.
Contudo, alguma classe vai ter que implementar a comunicação real com o dispositivo, e eu gostaria de testa-la tambem. Como fazer?
* Nesse projeto estou utilizando Delphi, mas como não conheço um forum de alto nível sobre Delphi resolvi perguntar aqui no de Java, pois acho que esse problema é independente de linguagem. Espero que não tenha nenhum problema
|
|
|
|