DCI com PHP

Flávio Gomes da Silva Lisboa www.fgsl.eti.br @fgsl

http://www.fgsl.eti/

Livre reprodução, desde que citada a fonte. www.fgsl.eti.br @fgsl

Quem sou eu

Autor

Instrutor

Arquiteto e DesenvolvedorCertificado

http://www.fgsl.eti.br/


Consultor



Especialista em história em quadrinhos http://perse.doneit.com.br

romocavaleirodoespaco.blogspot.com


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)

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.


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.

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

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.

MVC

O que é isso? Algum mnemômico para Twitter?

Model View Controller

Model

Controller

View

Model View Controller

View Model

Controller

Projeto MVC

Projeto MVC

<?phpnamespace Mvc\Controller;

abstract class Controller{

}

<?phpnamespace Mvc\View;

abstract class View{

}

<?phpnamespace Mvc\Model;

abstract class Model{

}

Não ficou claro...

Então vamos recorrer às analogias.

Modelo

Visão

Controlador

Capitão Marvel

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.

Contexto

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.

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.

MVCU?Mas onde foi parar o U?

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.

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.

Análise e Modelagem de Papéis Orientada a Objetos

Precursora da UML

Papel

Casode Uso

Responsabilidade

Análise e Modelagem de Papéis Orientada a Objetos

<?phpnamespace Arquitetura\OORAM;

class Papel{ public function responsabilidade() { }}

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.

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.

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.

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.

Operações de Sistema: Separação de Interesses

Execução de tarefas em um sistema

Contexto

Operação

Mensagem

Operações de Sistema: Executadas por Contexto


<?phpclass Context{

}



public function executarAtividade1(){ $this->outroContexto->executarAtividade2();}

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.

Essas formas trazem uma nova arquitetura

Papéis repletos de métodos (responsabilidades)

Cla

sses

de

Do m

íni o Casos de Uso

Ident ificad ores e papé is se m

Mé

todos

cc


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.


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.


<?phpinterface Compromisso{public function cumprir();}

<?phpinterface Contrato{public function respeitar();}

<?phpinterface Responsabilidade{public function ter();}


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.

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.

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.

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.

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?

Palavras-chave

Herança, Reuso, Lean Archicteture

Dependência, Composição, Contexto

Palavras-chave

Acoplamento

X

Desacoplamento

É hora de conhecer DCI

O que é isso? Um mnemônico para mensagens instantâneas?

“DCI pra gente tomar um café!”

Data Context Interaction

Data

Context

Interaction


InteractionData

Context

Projeto DCI

<?phpnamespace Dci\Context;

abstract class Context{

}

<?phpnamespace Dci\Interaction;

abstract class Interaction{

}

<?phpnamespace Dci\Data;

abstract class Data{

}


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

Contexto

Interação

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

Solução para os problemas de composição

Traits Injeção de dependências

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.

PHP >= 5.4

trait [nome] {

[bloco de código]

}

class [nome] extends [nome] {

use [nome];

}

namespace Tomarre\Helper;class Url{public function __construct(Request $request){$this->request = $request;}public function setRouter(Router $router){$this->router = $router;}}

Injeção de dependências

c

Injeção de dependências

use Zend\Di\Definition,Zend\Di\Reference;$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

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.


Obrigado!

Flávio Gomes da Silva Lisboa

www.fgsl.eti.br

[email protected]



mailto:[email protected]

DCI com PHP

Technology

Transcript of DCI com PHP