Implementação, design ou arquitetura?

494 visualizações

Publicada em

Uma discussão sobre as diferentes facetas de um software

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
494
No SlideShare
0
A partir de incorporações
0
Número de incorporações
1
Ações
Compartilhamentos
0
Downloads
3
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Implementação, design ou arquitetura?

  1. 1. Implementação, design ou arquitetura?
  2. 2. Desenhar sistemas é uma tarefa difícil
  3. 3. E, ainda fazer com que sejam escaláveis e performáticos, mantendo uma alta qualidade interna e externa, é um desafio!
  4. 4. “Você deve enfrentar suas batalhas de design, sejam elas no nível macroarquitetural ou no humilde campo das instâncias” Craig Larman
  5. 5. Qual é a diferença de design e arquitetura de software?
  6. 6. design é feito em cima do que foi decidido pela arquitetura por isso o que faz parte da arquitetura é mais difícil de mudar
  7. 7. “Alguns padrões podem ser chamados arquiteturais, já que representam decisões importantes sobre essas partes; outros são mais sobre design e o ajudam a implementar essa arquitetura” Martin Fowler
  8. 8. “Alguns padrões podem ser chamados arquiteturais, já que representam decisões importantes sobre essas partes; outros são mais sobre design e o ajudam a implementar essa arquitetura” Martin Fowler “Não faço nenhuma forte tentativa de separar esses dois, uma vez que aquilo que é arquitetural ou não é subjetivo”
  9. 9. '
  10. 10. “o termo arquitetura envolve a noção dos principais elementos do sistema, as peças que são mais difíceis de mudar”
  11. 11. Arquiteturas são as decisões que gostaríamos de ter tomado no começo do projeto Ralph Johnson (do GoF)
  12. 12. Uma vez que somente implementações são concretas, todo tipo de mudança implica em conhecer a implementação!
  13. 13. public class Conta { private BigDecimal saldo = BigDecimal.ZERO; private BigDecimal limite = BigDecimal.ZERO; private Cliente titular; private int numero; private Calendar dataAbertura; public void setNumero(int numero) { this.numero = numero; } public void setDataAbertura(Calendar dataAbertura) { this.dataAbertura = dataAbertura; } public int getNumero() { return numero; } public Calendar getDataAbertura() { return dataAbertura; } …
  14. 14. public class Conta { private BigDecimal saldo = BigDecimal.ZERO; private BigDecimal limite = BigDecimal.ZERO; private Cliente titular; private int numero; private Calendar dataAbertura; public Conta(int numero, Calendar dataAbertura) { setNumero(numero); setDataAbertura(dataAbertura); } private void setNumero(int numero) { this.numero = numero; } private void setDataAbertura(Calendar dataAbertura) { this.dataAbertura = dataAbertura; } public int getNumero() { return numero; }
  15. 15. public class Conta { private BigDecimal saldo = BigDecimal.ZERO; private BigDecimal limite = BigDecimal.ZERO; private Cliente titular; private int numero; private Calendar dataAbertura; public Conta(int numero, Calendar dataAbertura, BigDecimal saldoInicial, MaisUmMonteDeParametros... ) { setNumero(numero); setDataAbertura(dataAbertura); setSaldo(saldoInicial); … } private void setNumero(int numero) { this.numero = numero; } private void setDataAbertura(Calendar dataAbertura) { this.dataAbertura = dataAbertura; }
  16. 16. public class TestaBuilder { public static void main(String[] args) { Conta conta = ContaBuilder.novaConta() .comNumero(456) .comDataDeAbertura(2012, 04, 20) .eDepositoInicial("100") .toConta(); conta.saca(new BigDecimal("50")); System.out.println(conta.getSaldo()); } }
  17. 17. Uma boa implementação, design ou arquitetura: É aquela que permite modificações causando somente um impacto considerado justo a outras partes do sistema
  18. 18. Conhecer profundamente as ferramentas é o primeiro passo para poder fazer as perguntas corretas ao enfrentar o cenário de uma nova aplicação
  19. 19. Por onde começar? Boas práticas de OO TDD – Test-Driven Design
  20. 20. “Vale lembrar que precisamos de mais de 10 mil horas, ou 10 anos, para dominar uma linguagem” Peter Norvig

×