5. s.o.l.i.d.
“...5 princípios básicos de programação
orientada à objetos, quando aplicados de
forma conjunta visam garantir a facilidade
de manutenção e evolução ao longo do
tempo de vida de um software...”
Uncle Bob
6. s.o.l.i.d.
Single
Responsibility
Dependency Open
Inversion Closed
SOLID
Interface Liskov
Segregation Substitution
28. design patterns
abstract factory
fornece uma interface para criar
famílias de objetos relacionados ou
dependentes sem especificar
suas classes concretas
30. design patterns
builder
separa 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
37. design patterns
adapter
converte a interface de uma classe em outra
interface esperada pelos clientes,
permite que classes trabalhem juntas mesmo
com interfaces incompatíveis
41. design patterns
composite
compõe objetos em estruturas de árvore para
representar hierarquias parte-todo,
permite que clientes tratem
objetos individuais e composições de objetos
de maneira uniforme
43. design patterns
decorator
anexa responsabilidades adicionais
a um objeto de forma dinâmica,
fornecendo uma alternativa
flexível para extensão de comportamento
45. design patterns
facade
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
54. design patterns
strategy
define uma família de algoritmos,
encapsula cada um, e torna-os intercambiáveis,
permite que o algoritmo varie
independentemente dos clientes que o utilizam
56. design patterns
template method
define o esqueleto de um algoritmo
deixando alguns passos para as subclasses
redefinirem algumas etapas
sem alterar a estrutura do algoritmo
58. design patterns
visitor
representa 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
60. design patterns
observer
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
66. ioc – di
inversion 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. ioc – di
inversion 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
71. ioc – di
dependency injection
uma forma prática de aplicar o conceito de
IoC, diminuindo o acoplamento
entre uma classe e suas dependências
72. ioc – di
dependency 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
93. functions
extensions
permite adicionar novos comportamentos
em objetos, sem a necessidade de derivar
de um tipo base, implementar uma interface
ou até mesmo recompilar o código
96. tpl – async/await
conceitos
síncrono:
thread é bloqueada até que o
processamento seja finalizado
assíncrono:
thread não é bloqueado até que
o processamento seja finalizado
100. tpl – async/await
task 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. tpl – async/await
task 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
103. tpl – async/await
task 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
122. tdd
test-driven development
3 – elimine a 1 – escreva um
redundância teste que falhe
vermelho
refactoring verde
2 – escreva um código
para passar no teste
125. tdd
test-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!