Patterns:Onde?Quando?

Programação Arquitetura
#81

[quote=cv]De acordo com todo o resto do post do Fabio, mas tem uma omissao gigantesca na brincadeira toda. Consertando:

while (projetoEmAndamento) { testa(); defineProximasTarefas(); codifica(); refatora(); testa(); }[/quote]

Gostei do Refactoring :D.
Só me diz uma coisa CV, esta é a ordem que tu prefere??

codifica(); refatora();

ou seria algo assim:

refatora(); codifica(); refatora();

Pergunto isso, porque é normal o cara fazer um refactoring antes de sair mexendo, claro se isso for necessário.

]['s

#82

O que acham do Power Design-pattern KISS?
(Keep It Simple Stupid!)? :mrgreen:

#83

Esclarecendo…

è necessário planejamento sim, e focado sim nos releases.

Não to confundindo com o processo todo, só estava abstraindo a coisa por demais ehhe

Só queria mesmo dizer quer deve-se planejar ou falhará, e que estes planejamentos sejam o menores possíveis ou seja, por releases, e que isso deve ser entregue ao cliente depois de testado e tudo mais.

#84

isso mesmo, planejamento é importante em qualquer coisa que vc for fazer, não so em sistemas.

so que palnejar coisas pequenas(releases) é mais facil do que coisas grandes(projeto).

planeje o projeto, mas apenas para ter uma referencia, foque no planejamento das tarefas, e se esse palnejamento exigir, mude sua referencia.

[]'s

#85

Abstraindo partes do framework não quer dizer que voce irá esconde-lo.

criando por ex uma classe Criterio você pode ir adicionando os recursos da classe Criteria que for utilizando e ainda utiliza tudo isso que você falou.
Você não precisa adivinhar tudo.

O segredo é separar as responsabilidades para ir implementando. É lógico que sempre é mais dificil na primeira vez, mas depois colhera os beneficios.

Enquanto os interceptors não precisa ser abstraido pois é parte da implementação e não da interface. o que importa que nas classes de negocio que contém o código pesado você abstrai a implementação.

#86

E pra que voce vai enfiar uma classe Criterio, que nao faz parte do seu modelo de negocio, so pra abstrair o framework? Eh trabalho inutil, jprogrammer. A primeira coisa que qualquer um olhando um codigo desse vai fazer ao ter que dar manutencao vai ser arrancar essa classe dai e expor o Hibernate, pra poder entender o que esta acontecendo direito. Entao, pra que colocar ela la? :?

#87

Para mim expor o framework é mesma coisa que colocar a select no meio do código.
Agora me fale que por acaso você também coloca aquele HQL no meio da camada de negócio ?
Aí eu desisto !!!

#88

Rapazes, que tal um suco de NONI para refrescar? :mrgreen:

#89

Onde voce poe? :wink:

#90

dentro do DAO

O que eu insisto: A camada de negócio deve ver apenas a interface
ex:

class NotasFiscaisDao
{
    public void darBaixa(int mes)
    {
        String hql = "update .....";
       // faz o resto;
    } 
}

class NotasFiscais
{
    public void darBaixaMes()
    {
       NotasFiscaisDao.darBaixa(Meses.JANEIRO);
    }
}
#91

Onde voce poe? ;)[/quote]

Dentro dos XML do Hibernate. :mrgreen:

#92

Taí uma solução interessante…

#93

Olá

[quote=jgbt]faça sempre o minimo que atenda as necessidades do cliente de forma mais simples possivel.
tenha um codigo bem testado, e integrado constantemente.

com isso, qualquer mudança ou implementação nova, torna-se relativamente tranquila de agregar.

não pense no “se”, ou achando que se tal coisa mudar, seu sistema estara pronto p/ mudanças.

mais de 80% das funcionalidades do word, não são usadas pela maioria dos usuario.vc paga(e caro), por um produto que vai ser sub aproveitado.
se ele fizesse o minimo que atendesse as necessidades reais do usuario, com certeza sairia mais barato.
tudo bem que o objetivo da MS é outro, mas foi so um exemplo.
[/quote]

Neste tópico li algumas coisas que não concordei mas esta mensagem realmente merece 5 estrelas.

[]s
Luca

#94

Alguma coisa com o que vc nao concordou em especifico, Luca? Poe mais lenha na fogueira :wink:

#95

E olha que para o Luca colocar lenha na fogueira não é difícil!

É só ele não colocar o Olá no início da mensagem dele que logo será motivo para percebermos que alguma coisa está errada! Vou tirar 4 estrelas no Luca por que ele não colocou lenha na fogueira!!!
:lol: :lol: , brincadeira!!!

abraços!

#96

Muita gente confunde simples com simplório.
Concordo que temos que fazer o estritamente necessario, mas de uma forma organizada.
Ninguem tem bola de cristal para adivinhar o que poderá acontecer, mas separar resposabilidades no sistema, auxilia na manutenção e simplifica.
Esse negócio de camadas e patterns não foi feito de bobeira…

Ter estrutura elaborada não quer dizer funcionalidades extras…

#97

[quote=jprogrammer] Muita gente confunde simples com simplório.
Concordo que temos que fazer o estritamente necessario, mas de uma forma organizada.[/quote]

Tá ai…
É muito mais fácil organizar o que é simples!!! Por isso devemos nos preocupar apenas com o que é necessário!!

#98

Ola

(sem acentos pois acabei de trocar o teclado)

Este topico foi otimo. Muita coisa inteligente foi dita. Acredito que o jprogrammer tenha aproveitado bastante. Vamos ao que discordo e que jah foi por demais debatido (muito bem por sinal)

  1. Com a insistencia em abstrair o framework (mas no exemplo apareceu HQL no DAO). Nao vejo nenhuma vantagem nisto ate porque eh dificil trocar de framework.

  2. Com a insistencia em reinventar a roda (soh vale se for para aprender). Eu jah desenvolvi muitas bibliotecas mas foi no tempo em que nao havia solucoes prontas free.

[]s
Luca

#99