Arquitetura mix thiagoboufleuhr

230 visualizações

Publicada em

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
230
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Arquitetura mix thiagoboufleuhr

  1. 1. Thiago Boufleuhr Arquiteto de SoluçõesBem vindo!segunda-feira, 10 de dezembro 2012
  2. 2. agenda f(x)
  3. 3. agenda@ ?
  4. 4. s.o.l.i.d.Alguns tópicos podem ferir seus sentimentos.
  5. 5. s.o.l.i.d. “...5 princípios básicos de programação orientada à objetos, quando aplicados de forma conjunta visam garantir a facilidadede manutenção e evolução ao longo do tempo de vida de um software...” Uncle Bob
  6. 6. s.o.l.i.d. Single ResponsibilityDependency Open Inversion Closed SOLID Interface Liskov Segregation Substitution
  7. 7. s.o.l.i.d.fato! “...você não programa orientado a objetos...”
  8. 8. s.o.l.i.d.single responsibility principle...um objeto deve possuir apenas uma única responsabilidade e apenas um motivo para mudar...
  9. 9. s.o.l.i.d.
  10. 10. s.o.l.i.d.open/closed principle...uma classe deve ser aberta para extensão e fechada para modificação...
  11. 11. s.o.l.i.d.
  12. 12. s.o.l.i.d.liskov substitution principle...objetos devem ser substituíveis pelo seu super tipo sem afetar o correto comportamento do sistema...
  13. 13. s.o.l.i.d.
  14. 14. s.o.l.i.d.
  15. 15. s.o.l.i.d.interface segregation principle...interfaces de granularidade alta para necessidades específicas do cliente...
  16. 16. s.o.l.i.d.
  17. 17. s.o.l.i.d.dependency inversion principle ...desenvolva para abstrações, não para classes concretas...
  18. 18. s.o.l.i.d.
  19. 19. s.o.l.i.d.
  20. 20. design patterns...soluções reutilizáveis para problemas recorrentes no desenvolvimento de software...
  21. 21. design patterns
  22. 22. design patterns
  23. 23. design patterns
  24. 24. design patterns
  25. 25. design patterns
  26. 26. design patterns
  27. 27. design patterns abstract factory builder prototype singleton
  28. 28. design patternsabstract factory fornece uma interface para criar famílias de objetos relacionados ou dependentes sem especificar suas classes concretas
  29. 29. design patternsabstract factory
  30. 30. design patternsbuildersepara a construção de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações
  31. 31. design patternsbuilder
  32. 32. design patternsprototype especifica um tipo de objeto a ser criado usando uma instância como protótipo para criar novos objetos
  33. 33. design patternsprototype
  34. 34. design patternssingleton garante que um objeto terá apenas uma instância e define um ponto único de acesso a essa instância
  35. 35. design patternssingleton
  36. 36. design patterns adapter bridge composite decorator facade proxy
  37. 37. design patternsadapterconverte a interface de uma classe em outra interface esperada pelos clientes,permite que classes trabalhem juntas mesmo com interfaces incompatíveis
  38. 38. design patternsadapter
  39. 39. design patternsbridge desacopla uma abstração da sua implementação para que ambas possam variar de forma independente
  40. 40. design patternsbridge
  41. 41. design patternscompositecompõe objetos em estruturas de árvore para representar hierarquias parte-todo, permite que clientes tratemobjetos individuais e composições de objetos de maneira uniforme
  42. 42. design patternscomposite
  43. 43. design patternsdecorator anexa responsabilidades adicionais a um objeto de forma dinâmica, fornecendo uma alternativa flexível para extensão de comportamento
  44. 44. design patternsdecorator
  45. 45. design patternsfacade fornece uma interface unificada para um conjunto de interfaces em um subsistema,define uma interface de nível mais elevado para abstrair a lógica de subsistemas complexos
  46. 46. design patternsfacade
  47. 47. design patternsproxypermite abstrair o objeto em uso através de uma interface comum, delegando a execução do comportamento ao mesmo
  48. 48. design patternsproxy
  49. 49. design patterns command  template method state  visitor strategy  observer
  50. 50. design patternscommandencapsula uma solicitação em forma de objeto, permite parametrizar as requisições ao longo das chamadas a esse objeto
  51. 51. design patternscommand
  52. 52. design patternsstate permite que um objeto altere seu comportamento quando seu estado interno muda, o objeto irá alterar seu tipo
  53. 53. design patternsstate
  54. 54. design patternsstrategy define uma família de algoritmos,encapsula cada um, e torna-os intercambiáveis, permite que o algoritmo varieindependentemente dos clientes que o utilizam
  55. 55. design patternsstrategy
  56. 56. design patternstemplate method define o esqueleto de um algoritmo deixando alguns passos para as subclasses redefinirem algumas etapas sem alterar a estrutura do algoritmo
  57. 57. design patternstemplate method
  58. 58. design patternsvisitorrepresenta uma operação a ser realizada sobre elementos de uma estrutura de objeto, permite que você defina uma nova operação sem alterar as classes dos elementos sobre os quais atua
  59. 59. design patternsvisitor
  60. 60. design patternsobserver define uma dependência um-para-muitos entre objetos, de modo que quando um objeto muda de estado, todos os seus dependentes são notificados e atualizados automaticamente
  61. 61. design patternsobserver
  62. 62. design patterns
  63. 63. design patterns
  64. 64. ioc – di
  65. 65. ioc – diinversion of control
  66. 66. ioc – diinversion of control uma classe não deve conhecer como suas dependências são criadas, somente a interface pública de acesso as mesmas
  67. 67. ioc – diinversion of control• desacopla componentes e camadas em um sistema• remove a responsabilidade de um componente resolver suas dependências• permite a troca da implementação em diferentes ambientes• permite que o componente seja testável (mock, unit test)• fornece um mecanismo para troca de recursos em uma aplicação
  68. 68. ioc – diinversion of control
  69. 69. ioc – diinversion of control
  70. 70. ioc – didependency injection
  71. 71. ioc – didependency injection uma forma prática de aplicar o conceito de IoC, diminuindo o acoplamento entre uma classe e suas dependências
  72. 72. ioc – didependency injection• permite que o componente seja testável (mock, unit test)• promove baixo acoplamento entre classes e subsistemas• adiciona flexibilidade potencial para futuras mudanças• habilita uma forma de reusar componentes para fins semelhantes• A implementação é simples e não precisa de um container de DI
  73. 73. ioc – didependency injection
  74. 74. ioc – didependency injection• Ninject - http://www.ninject.org/• Simple Injector - http://simpleinjector.codeplex.com/• Unity 2.1 - http://msdn.microsoft.com/en-us/library/dd203101.aspx• Structure Map - http://docs.structuremap.net/• Windsor - http://docs.castleproject.org/Active%20Record.MainPage.ashx• AutoFac - http://code.google.com/p/autofac/
  75. 75. ioc – didependency injection
  76. 76. ioc – didependency injection singleton
  77. 77. ioc – didependency injection transient
  78. 78. ioc – didependency injection combined
  79. 79. functionsanonymous
  80. 80. functions
  81. 81. functionsanonymousa partir do C# 2.0 foi introduzido o conceito de métodos anônimos (sem um nome)
  82. 82. functionsanonymouspermite declarar de forma in line um método sem a necessidade da lista de parâmetros
  83. 83. functionsanonymous todo método anônimo é um delegate
  84. 84. functionsanonymous
  85. 85. functionslambda
  86. 86. functionslambda uma expressão lambda é uma função anônima utilizada para criar delegates ou expression trees
  87. 87. functionslambdautilizada para criar funções anônimas locais, que podem ser passadas como parâmetros ou retornadas de outros métodos
  88. 88. functionslambdasubstitui a utilização de anonymous methods adicionando mais funcionalidades em sua execução
  89. 89. functionslambda (input parameters) => { statement; } (x, y) => x == y (int x, string s) => s.Length > x ( ) => MeuMetodo()
  90. 90. functionslambda
  91. 91. functionslambda
  92. 92. functionsextensions
  93. 93. functionsextensions permite adicionar novos comportamentos em objetos, sem a necessidade de derivarde um tipo base, implementar uma interface ou até mesmo recompilar o código
  94. 94. functionsextensions
  95. 95. tpl – async/await
  96. 96. tpl – async/awaitconceitos síncrono: thread é bloqueada até que o processamento seja finalizado assíncrono: thread não é bloqueado até que o processamento seja finalizado
  97. 97. tpl – async/awaitconceitos
  98. 98. tpl – async/awaitconceitos
  99. 99. tpl – async/await
  100. 100. tpl – async/awaittask parallel library define um conjunto de API’s públicas no namespace System.Threading responsável por abstrair a complexidade de trabalhar em ambientes multithreaded e de forma paralela
  101. 101. tpl – async/awaittask parallel library• trabalha com todos os processadores disponíveis• simplifica a aplicação do conceito• suporta cancelamento de execução (token)• gerenciamento de estado• melhora a performance do código particionando a execução lógica
  102. 102. tpl – async/awaittask parallel library
  103. 103. tpl – async/awaittask parallel library• nem todo código é desenhado para ser executado de forma paralela• pode criar um overhead quando utilizado de forma incorreta• necessário conhecer conceitos de: • locks • deadlocks • race conditions• não considere como sendo a forma mais rápida de execução• evite escrever em espaços compartilhados de memória (static)• evite chamar métodos que não são thread safe
  104. 104. tpl – async/awaittask parallel library
  105. 105. tpl – async/awaittask parallel library demo
  106. 106. tpl – async/awaitasync/await
  107. 107. tpl – async/awaitasync/await
  108. 108. tpl – async/awaitasync/await demo
  109. 109. tddtest-driven development
  110. 110. tddproblemática bom barato rápido
  111. 111. tddproblemática mais erros menos testes menos tempo
  112. 112. tddproblemática
  113. 113. tddproblemática
  114. 114. tddproblemática
  115. 115. tddproblemática
  116. 116. tddproblemática
  117. 117. tddproblemática
  118. 118. tddproblemática
  119. 119. tddproblemática
  120. 120. tddsolução: test-driven development “...remove o medo no desenvolvimento de software...” sinpo és dédi
  121. 121. tddtest-driven development
  122. 122. tdd test-driven development3 – elimine a 1 – escreva um redundância teste que falhe vermelho refactoring verde 2 – escreva um código para passar no teste
  123. 123. tddtest-driven development
  124. 124. tddtest-driven development
  125. 125. tddtest-driven development• assegura a qualidade do código• garante a existência de testes unitários• reduz a possiblidade de erros no código• simplifica o código, uma vez que somente o necessário é programado• define as interfaces entre os objetos (consumidor)• permite definir os componentes de forma desacoplada, flexível e extensível• documentação viva (runtime documentation)• garante seu emprego!
  126. 126. tddtest-driven development
  127. 127. tddtest-driven development
  128. 128. tddtest-driven development
  129. 129. tddtest-driven development
  130. 130. tddtest-driven development
  131. 131. tddtest-driven development
  132. 132. dúvidas
  133. 133. obrigado

×