Arquitetura mix thiagoboufleuhr

Thiago Boufleuhr
Arquiteto de Soluções

Bem vindo!
segunda-feira, 10 de dezembro 2012

s.o.l.i.d.

Alguns tópicos podem ferir
seus sentimentos.

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

s.o.l.i.d.
Single
Responsibility

Dependency Open
Inversion Closed

SOLID

Interface Liskov
Segregation Substitution

s.o.l.i.d.

fato!
“...você não programa
orientado a objetos...”

s.o.l.i.d.
single responsibility principle

...um objeto deve possuir apenas
uma única responsabilidade
e apenas um motivo para mudar...

s.o.l.i.d.
open/closed principle

...uma classe deve ser aberta para extensão
e fechada para modificação...

s.o.l.i.d.
liskov substitution principle

...objetos devem ser substituíveis pelo seu
super tipo sem afetar o correto
comportamento do sistema...

s.o.l.i.d.
interface segregation principle

...interfaces de granularidade alta para
necessidades específicas do cliente...

s.o.l.i.d.
dependency inversion principle

...desenvolva para abstrações,
não para classes concretas...

design patterns

...soluções reutilizáveis para
problemas recorrentes no
desenvolvimento de software...

design patterns

 abstract factory
 builder
 prototype
 singleton

design patterns
abstract factory

fornece uma interface para criar
famílias de objetos relacionados ou
dependentes sem especificar
suas classes concretas

design patterns
abstract factory

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

design patterns
prototype

especifica um tipo de objeto a ser criado
usando uma instância como protótipo
para criar novos objetos

design patterns
singleton

garante que um objeto terá apenas uma
instância e define um ponto único
de acesso a essa instância

design patterns

 adapter
 bridge
 composite
 decorator
 facade
 proxy

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

design patterns
bridge

desacopla uma abstração da sua
implementação para que ambas possam
variar de forma independente

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

design patterns
decorator

anexa responsabilidades adicionais
a um objeto de forma dinâmica,
fornecendo uma alternativa
flexível para extensão de comportamento

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

design patterns
proxy

permite abstrair o objeto em uso através de
uma interface comum, delegando a
execução do comportamento ao mesmo

design patterns

 command  template method
 state  visitor
 strategy  observer

design patterns
command

encapsula uma solicitação em forma de objeto,
permite parametrizar as requisições
ao longo das chamadas a esse objeto

design patterns
state

permite que um objeto altere seu
comportamento quando seu estado
interno muda, o objeto irá alterar seu tipo

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

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

design patterns
template method

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

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

ioc – di
inversion of control

ioc – di

uma classe não deve conhecer como suas
dependências são criadas, somente
a interface pública de acesso as mesmas

ioc – di

• 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

ioc – di
dependency injection

ioc – di

uma forma prática de aplicar o conceito de
IoC, diminuindo o acoplamento
entre uma classe e suas dependências

ioc – di

• 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

ioc – di

• 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/

ioc – di

singleton

ioc – di

transient

ioc – di

combined

functions
anonymous

a partir do C# 2.0 foi introduzido o conceito
de métodos anônimos (sem um nome)

functions
anonymous

permite declarar de forma in line um método
sem a necessidade da lista de parâmetros

functions
anonymous

todo método anônimo é um delegate

functions
lambda

uma expressão lambda é uma
função anônima
utilizada para criar delegates
ou expression trees

functions
lambda

utilizada para criar funções anônimas locais,
que podem ser passadas como parâmetros
ou retornadas de outros métodos

functions
lambda

substitui a utilização de anonymous methods
adicionando mais funcionalidades
em sua execução

functions
lambda

(input parameters) => { statement; }

(x, y) => x == y

(int x, string s) => s.Length > x

( ) => MeuMetodo()

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

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

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

tpl – async/await

• 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

tpl – async/await

tpl – async/await
• 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

tpl – async/await

demo

tpl – async/await
async/await

tpl – async/await
async/await

demo

tdd
problemática

bom

barato rápido

tdd
problemática

mais erros
menos testes

menos tempo

tdd
solução: test-driven development

“...remove o medo no
desenvolvimento de software...”

sinpo és dédi

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

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!

Arquitetura mix thiagoboufleuhr

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (9)

Semelhante a Arquitetura mix thiagoboufleuhr

Semelhante a Arquitetura mix thiagoboufleuhr (20)

Arquitetura mix thiagoboufleuhr