O documento defende que o padrão DCI (Data Context Interaction) é melhor do que MVC para arquitetura de software orientada a objetos. Apresenta os princípios do DCI, como a separação de dados, contexto e interação, e argumenta que ele resolve problemas de composição encontrados em MVC.
1. MVC já era! O negócio é DCI!
Flávio Gomes da Silva Lisboa
www.fgsl.eti
@fgsl
2. Quem sou eu
Flávio Gomes da Silva Lisboa
Bacharel em Ciência da Computação
Especialista em Aplicações Corporativas usando Orientação a
Objetos e Tecnologia Java
Instrutor e Consultor
www.fgsl.eti.br
flavio.lisboa@fgsl.eti.br
Livre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl
8. Arquitetura de Software
Arquitetura é a essência da estrutura: é a forma
A estrutura ofusca a forma
Arquitetura Enxuta: entrega sob demanda de
funcionalidades, o que realmente gera valor.
Arquitetura Ágil: a que suporta mudança,
interação com o usuário final, descoberta e fácil
compreensão (de funcionalidades)
10. Lean Architecture
“Arquitetura Enxuta”
O “Pensamento Enxuto” (Lean Thinking),
surgiu no final dos anos 80 do século XX, em
um projeto do MIT sobre a indústria
automobilística mundial.
A pesquisa mostrou que a Toyota havia
desenvolvido um novo paradigma de gestão
nas principais dimensões dos negócios.
Em 2009, a Toyota tornou-se a maior em
volume de vendas, mostrando as vantagens e
benefícios do sistema que desenvolveu.
11. Lean Architecture
“Arquitetura Enxuta”
O “Pensamento Enxuto” é uma estratégia de
negócios para aumentar a satisfação dos
clientes através da melhor utilização dos
recursos.
O foco da implementaçao deve estar nas reais
necessidades dos negócios.
12. Qual o valor da arquitetura?
A arquitetura suporta “o que acontece lá”.
Código habitável – pelas pessoas que
desenvolvem e pelas pessoas que o usam.
A arquitetura é o que faz o código parecer
familiar.
Uma boa arquitetura reduz lixo e inconsistência
-
Menos retrabalho
Consistência do sistema
13. Arquitetura e
Orientação a Objetos
Orientação a Objetos (OO) é um paradigma –
um modo de falar sobre a forma.
Fundamentos de OO: capturar o modelo
mental do usuário final no código.
OO captura
As entidades (objetos) que os usuários conhecem
As classes que servem como conjuntos de tais
objetos.
14. MVC
O que é isso?
Algum mnemômico para Twitter?
24. Remember, remember...
Um mesmo nome identifica duas entidades
distintas.
O nome por si só, não tem nenhum significado.
O nome é apenas um dado.
Mas o dado, dentro de um contexto, traz
informação para o receptor.
25. MVC é a encarnação da visão OO
O modelo mental do usuário é introduzido no
código.
O objetivo das visões é a manipulação direta –
a interação com o usuário.
O objetivo do controlador é coordenar
múltiplas visões. Os dados do modelo podem
ser apresentados de várias formas.
26. Como nasceu o MVC
O cientista norueguês
Trygve Reenskaug estava
desencantado com a
arquitetura das linguagens
Simula e Smalltalk.
Em 1978, ele apresentou
um padrão de projeto
chamado Model-View-
Controller-User.
28. Os objetivos do MVCU
Deixar que os usuários interagissem
diretamente com o código que foi projetado
como uma reflexão de seus próprios modelos
mentais. É pra isso que serve a visão.
Permitir que o usuário coordene várias visões
simultâneas do mesmo modelo. É pra isso que
serve o controlador.
Isso é baseado na hipótese de que basta
modelar a noção que o usuário final tem sobre
o sistema de objetos.
29. Mas arquitetura é mais do que isso
A forma do domínio de negócio
O que o sistema é.
Modelo de Domínio (como no MVC).
Com o que o programador se preocupa.
A forma das interações do sistema
O que o sistema faz.
Modelos de papéis: OORAM (Object Oriented Role
Analysis and Modeling).
Com o que o usuário se preocupa.
30. Análise e Modelagem de Papéis
Orientada a Objetos
Precursora da UML
Caso
de Uso
Papel Responsabilidade
31. De volta a OO: Outras formas na
cabeça do usuário final
Usuários pensam mais sobre os papéis
manipulados por objetos do que nos objetos.
O que o sistema faz, novamente!
Dinheiro transferido de uma conta bancária: os
papéis são a conta de origem e a conta de destino.
Os objetos poupança, conta de investimento
podem todos fazer uso desses papéis.
As associações de papéis para objetos, para
um dado caso de uso, também é parte do
modelo do usuário final.
32. Ainda mais formas!
E o algoritmo?
O algoritmo também tem forma na cabeça do
usuário.
Inicia a transação.
Debita a conta de origem.
Credita a conta de destino.
Finaliza a transação.
33. De volta a OO: Outras formas na
cabeça do usuário final
O usuário está mais preocupado com as
responsabilidades que são carregadas no
sistema.
A orientação a objetos tem servido aos
programadores (o processo de descoberta, a
arquitetura) mas não aos usuários e clientes –
e muito menos à qualidade do software.
34. Operações de Sistema:
Separação de Interesses
Computadores podem:
Armazenar e recuperar dados +
Transformar dados +
Comunicarem-se!!!
A comunicação torna-se cidadã de primeira
classe na computação.
Programação orientada a classes: noodles
DCI: Separação de interesses:
Cada tarefa codificada separadamente)
35. Operações de Sistema:
Separação de Interesses
Execução de tarefas em um sistema
Mensagem
Operação
Contexto
40. Operações de Sistema:
Executadas por Contextos
Um Contexto (uma instância de uma classe de
contexto).
Recebe uma mensagem.
É responsável por uma operação de sistema.
Dispara um método no primeiro papel.
A execução continua como especificado nos
métodos do papel.
41. Essas formas trazem uma nova
arquitetura
Papéis repletos de métodos (responsabilidades)
Casos de Uso
Classes de Domínio
papéis sem Métodos
Identificadores e
c
c
42. Essas formas trazem uma nova
arquitetura
A proposta de Trygve para uma nova arquitetura
é suportar a visão do usuário dos casos de uso
e localizar algoritmos em um papel
encapsulado.
43. Essas formas trazem uma nova
arquitetura
Uma das formas maioreis dessa arquitetura,
chamada forma (ou arquitetura),
comportamental) básica, definida apenas em
termos de protocolos de papéis. Esses são os
papéis sem métodos.
Compromissos.
Contratos.
Responsabilidades.
44. Essas formas trazem uma nova
arquitetura
O que Trygve adiciona são os papéis com
métodos. Esses papéis podem invocar métodos
próprios ou de outro papel.
45. Papéis com Métodos
Esses papéis são implementados como classes.
Cada papel com métodos é injetado dentro de
uma classe cujos objetos manipulam aquele
papel em algum momento de seu tempo de vida.
A injeção é um tipo de operação de “colagem”,
onde a lógica dos papéis com métodos é
adicionada à lógica das classes.
Cada classe se comportará de acordo com os
métodos dos papéis que foram “copiados” para
dentro dele.
46. Casos de Uso
Cada cenário de caso de uso é implementado
como uma interação de algoritmos entre
papéis.
Isso é um tipo de decomposição funcional, pois
muitos usuários decompõem tarefas complexas
em subtarefas.
Em tempo de execução, associamos um papel
sem métodos com um objeto que pode suportar
os contratos, compromissos, daquele papel e
deixamos o cenário ocorrer.
47. Composição de Classes
Precisamos compor algoritmos genéricos (pense
em trechos de código), de papéis com métodos
com as classes cujos objetos manipulam esses
papéis.
Estamos falando de colar pedaços de código, e
não classes inteiras.
Entramos em um problema que não é resolvido
pela mecanismo fundamental de reuso da
orientação a objetos, a herança.
48. Composição de Classes
Um objeto pode ter papéis variáveis de acordo
com o contexto em que está operando.
Um objeto pode adquirir responsabilidades em
tempo de execução.
Como atribuir poderes para um objeto que não
foram definidos previamente?
Como estabelecer a dependência entre objetos
em tempo de execução?
54. Data Context Interaction
Quando estudamos um negócio, também devemos ter esse tipo
de preocupação. Separamos a Visão da Estrutura da Visão dos
Processos, cientes da maior complexidade e volatilidade da
segunda. Costumo dizer em meus treinamentos que a Visão dos
Processos ocupará, no mínimo, 70% do tempo de um analista
de negócios. Acontece que a aplicação tradicional ou
indisciplinada de conceitos OO, em determinado momento,
mistura tudo. Através do padrão DCI essa separação é sempre
respeitada. Entre a estrutura (Data, o D de DCI) e o-que-o-
sistema-FAZ (Interaction), sempre há um Contexto. E um Contexto
é uma representação fiel de… um Caso de Uso!
Paulo Vasconcelos, Finito Consultoria
58. Como nasceu o DCI?
Podemos considerar a publicação do artigo
“The DCI Architecture: A New Vision of Object-
Oriented Programming”, de James O'Coplien
e … Trygve Reenskaug, em 2009
The Brave and The Bold
59. Solução para os problemas de
composição
Traits
Injeção de dependências
60. Traits
Traits: Composing Classes from Behavioral
Building Blocks
Dissertação de Nathanael Scharli.
Apresentada na Philosophisch-
naturwissenschaftlichen Fakultat der Universitat
Bern em 2005.
Um simples modelo composicional que estende
a herança simples.
61. PHP 5.4
trait [nome] {
[bloco de código]
}
class [nome] extends [nome] {
use [nome];
}
62. Injeção de dependências
namespace TomarreHelper;
class Url
{
public function __construct(Request $request)
{ c
$this->request = $request;
}
public function setRouter(Router $router)
{
$this->router = $router;
}
}
63. Injeção de dependências
use ZendDiDefinition,
ZendDiReference;
$mongo = new Definition('Mongo');
$mongoDB = new Definition('MongoDB');
$mongoDB->setParam('conn', new Reference('mongo'))
->setParam('name', 'test');
$coll = new Definition('MongoCollection');
$coll->setParam('db', new Reference('mongodb'))
->setParam('name', 'resource');
$di->setDefinitions(array(
'mongo'=> $mongo,
'mongodb' => $mongoDB,
'resource' => $coll,
));
$resource = $di->get('resource');
2
64. Ou seja...
Muita gente fala de MVC, mas
poucos o implementam direito.
Exemplo disso é a proliferação
de modelos magros e
controladores gordos.
DCI não substitui MVC, apenas
o complementa.
65. Obrigado!
Flávio Gomes da Silva Lisboa
www.fgsl.eti.br
flavio.lisboa@fgsl.eti.br
Livre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl