DCI com PHP

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

Quem sou eu

Autor

Arquiteto e Desenvolvedor
Certificado

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

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”

Lean Architecture
 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.

Lean Architecture
 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

View

Controller

Model

Model View Controller

Controller

View Model

Projeto MVC
<?php
namespace MvcModel;

abstract class Model
{

}

<?php
namespace MvcView;

abstract class View
{

}

<?php
namespace MvcController;

abstract class Controller
{

}

Não ficou claro...

 Então vamos recorrer às analogias.

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.

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

Caso
de Uso

Papel Responsabilidade

Análise e Modelagem de Papéis
Orientada a Objetos
<?php
namespace ArquiteturaOORAM;

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.

Separação de Interesses
 Execução de tarefas em um sistema

Mensagem

Contexto
Operação

Executadas por Contexto

<?php
class Context
{

}


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

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)

Casos de Uso
Classes de Domínio

papéis sem Métodos
Identificadores e
c
c

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.

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.

arquitetura
<?php
interface Compromisso
{
public function cumprir();
}

<?php
interface Contrato
{
public function respeitar();
}

<?php
interface Responsabilidade
{
public function ter();
}

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.

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

Interaction

Context

Data


Context

Interaction
Data

Projeto DCI
<?php
namespace DciData;

abstract class Data
{

}

<?php
namespace DciInteraction;

abstract class Interaction
{

}

<?php
namespace DciContext;

abstract class Context
{

}


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

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];
}

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;
}
}

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,
));

2
$resource = $di->get('resource');

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
flavio.lisboa@fgsl.eti.br


DCI com PHP

Mais conteúdo relacionado

Mais procurados (19)

Semelhante a DCI com PHP (20)

Mais de Flávio Lisboa (20)

Último (19)

DCI com PHP