MVC já era! O negócio é DCI!

12,468
-1

Published on

Palestra sobre o padrão de arquitetura DCI. Proferida na PHP Conference Brasil

2 Comments
7 Likes
Statistics
Notes
No Downloads
Views
Total Views
12,468
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
136
Comments
2
Likes
7
Embeds 0
No embeds

No notes for slide

MVC já era! O negócio é DCI!

  1. 1. MVC já era! O negócio é DCI! Flávio Gomes da Silva Lisboa www.fgsl.eti @fgsl
  2. 2. Quem sou eu Flávio Gomes da Silva Lisboa Bacharel em Ciência da ComputaçãoEspecialista 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
  3. 3. Arquitetura
  4. 4. Arquitetura
  5. 5. Arquitetura(colocando medo nos corações)
  6. 6. Arquitetura(colocando medo nos corações)
  7. 7. Arquitetura(colocando medo nos corações)
  8. 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)
  9. 9. Lean Architecture“Arquitetura Enxuta”
  10. 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. 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. 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. 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. 14. MVC O que é isso?Algum mnemômico para Twitter?
  15. 15. Model View Controller View Controller Model
  16. 16. Model View Controller Controller View Model
  17. 17. Projeto MVC
  18. 18. Não ficou claro... Então vamos recorrer às analogias.
  19. 19. Modelo
  20. 20. Visão
  21. 21. Controlador
  22. 22. Capitão Marvel
  23. 23. Capitão Marvel
  24. 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. 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. 26. Como nasceu o MVCO cientista norueguêsTrygve Reenskaug estavadesencantado com aarquitetura das linguagensSimula e Smalltalk.Em 1978, ele apresentouum padrão de projetochamado Model-View-Controller-User.
  27. 27. MVCU?Mas onde foi parar o U?
  28. 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. 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. 30. Análise e Modelagem de Papéis Orientada a Objetos Precursora da UML Caso de Uso Papel Responsabilidade
  31. 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. 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. 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. 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. 35. Operações de Sistema: Separação de Interesses Execução de tarefas em um sistema Mensagem Operação Contexto
  36. 36. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  37. 37. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  38. 38. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  39. 39. Operações de Sistema: Executadas por Contexto Execução de tarefas em um sistema
  40. 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. 41. Essas formas trazem uma nova arquitetura Papéis repletos de métodos (responsabilidades) Casos de UsoClasses de Domínio papéis sem Métodos Identificadores e c c
  42. 42. Essas formas trazem uma nova arquiteturaA proposta de Trygve para uma nova arquiteturaé suportar a visão do usuário dos casos de usoe localizar algoritmos em um papelencapsulado.
  43. 43. Essas formas trazem uma nova arquiteturaUma das formas maioreis dessa arquitetura,chamada forma (ou arquitetura),comportamental) básica, definida apenas emtermos de protocolos de papéis. Esses são ospapéis sem métodos. Compromissos. Contratos. Responsabilidades.
  44. 44. Essas formas trazem uma nova arquiteturaO que Trygve adiciona são os papéis commétodos. Esses papéis podem invocar métodospróprios ou de outro papel.
  45. 45. Papéis com MétodosEsses papéis são implementados como classes.Cada papel com métodos é injetado dentro deuma classe cujos objetos manipulam aquelepapel 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 osmétodos dos papéis que foram “copiados” paradentro dele.
  46. 46. Casos de UsoCada cenário de caso de uso é implementadocomo uma interação de algoritmos entrepapéis.Isso é um tipo de decomposição funcional, poismuitos usuários decompõem tarefas complexasem subtarefas.Em tempo de execução, associamos um papelsem métodos com um objeto que pode suportaros contratos, compromissos, daquele papel edeixamos o cenário ocorrer.
  47. 47. Composição de ClassesPrecisamos compor algoritmos genéricos (penseem trechos de código), de papéis com métodoscom as classes cujos objetos manipulam essespapéis.Estamos falando de colar pedaços de código, enão classes inteiras.Entramos em um problema que não é resolvidopela mecanismo fundamental de reuso daorientação a objetos, a herança.
  48. 48. Composição de ClassesUm objeto pode ter papéis variáveis de acordocom o contexto em que está operando.Um objeto pode adquirir responsabilidades emtempo de execução.Como atribuir poderes para um objeto que nãoforam definidos previamente?Como estabelecer a dependência entre objetosem tempo de execução?
  49. 49. Palavras-chave Herança, Reuso, Lean ArchictetureDependência, Composição, Contexto
  50. 50. Palavras-chave Acoplamento XDesacoplamento
  51. 51. É hora de conhecer DCI O que é isso? Um mnemônico para mensagens instantâneas? “DCI pra gente tomar um café!”
  52. 52. Data Context Interaction Interaction Context Data
  53. 53. Data Context Interaction Context Interaction Data
  54. 54. Data Context InteractionQuando estudamos um negócio, também devemos ter esse tipode preocupação. Separamos a Visão da Estrutura da Visão dosProcessos, cientes da maior complexidade e volatilidade dasegunda. Costumo dizer em meus treinamentos que a Visão dosProcessos ocupará, no mínimo, 70% do tempo de um analistade negócios. Acontece que a aplicação tradicional ouindisciplinada de conceitos OO, em determinado momento,mistura tudo. Através do padrão DCI essa separação é semprerespeitada. 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
  55. 55. Dados
  56. 56. Contexto
  57. 57. Interação
  58. 58. Como nasceu o DCI? Podemos considerar a publicação do artigo “The DCI Architecture: A New Vision of Object- Oriented Programming”, de James OCoplien e … Trygve Reenskaug, em 2009 The Brave and The Bold
  59. 59. Solução para os problemas de composição Traits Injeção de dependências
  60. 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. 61. PHP 5.4trait [nome] {[bloco de código]}class [nome] extends [nome] { use [nome];}
  62. 62. Injeção de dependênciasnamespace TomarreHelper;class Url{public function __construct(Request $request){ c$this->request = $request;}public function setRouter(Router $router){$this->router = $router;}}
  63. 63. Injeção de dependênciasuse 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. 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. 65. Obrigado! Flávio Gomes da Silva Lisboa www.fgsl.eti.br flavio.lisboa@fgsl.eti.brLivre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×