D de SOLID: Reduzindo o vendor lock-in em aplicações PHP

D de SOLID: Reduzindo o vendor
lock-in em aplicações PHP
Flávio Gomes da Silva Lisboa, Ph. D.
www.fgsl.eti.br

Quem sou eu?
●
Mestre e doutor em Tecnologia e Sociedade pela UTFPR;
●
Cientista da computação, com especialização em programação
orientada a objetos e Tecnologia Java;
●
Engenheiro e arquiteto certificado pela Zend;
●
Analista de sistemas e programador com mais de duas décadas
de experiência;
●
Professor de ensino médio e técnico, com experiência no ensino
superior e em cursos corporativos.
‘

FREE/LIBRE E OPEN SOURCE
SOFTWARE

Quem sou eu?
●
Autor dos livros:

Escrevo sobre Zend Framework desde 2008

Escrevi o primeiro livro exclusivo sobre Symfony

Quem sou eu?
●
Autor do livro:

Preâmbulo
Tudo que falaremos aqui trata de manutenção de
software. Se você vai fazer software pra ser
jogado fora, não há aplicação para o que
falaremos.

Preâmbulo
Mas se você vai fazer software que será mantido,
atualizado, evoluído e aperfeiçoado, então
deveria se preocupar com os tópicos que
abordaremos.

Mudança: requisito não funcional

Não se pode
entrar duas
vezes no
mesmo rio
Ἡράκλειτος ὁ Ἐφέσιος
Heráclito, de Éfeso

TEM UM
BUG, E
AGORA?
A LEI
MUDOU, E
AGORA?
O CLIENTE
MUDOU DE
IDEIA, E
AGORA?

A MUDANÇA
É
INEVITÁVEL!

É melhor estar preparado para a mudança

Arquitetura de software não é
arquitetura de sistema
Como substantivo,
arquitetura pode ser
resumida como sendo
sobre estrutura.

Como verbo, arquitetura (ou
seja, o processo, arquitetar)
trata de entender o que você
precisa construir, criar uma
visão para construí-lo e tomar
as decisões de design
apropriadas.

Arquitetura de sistema é
uma mistura de software e hardware.
Na arquitetura de sistema, você se preocupa com
as máquinas onde o software será executado.
E a escolha de um hardware específico antes do
software pode limitar o software a ser utilizado.

Se você escolhe a casa antes dos móveis, os
móveis serão limitados pela casa.
Se você escolhe os móveis antes da casa, a casa
será limitada pelos móveis.

Quando pensamos em
desenvolvimento de software como
desenvolvedores de software, a
maior parte do nosso foco é
colocada no código. Aqui, estamos
pensando em coisas como princípios
orientados a objetos, classes,
interfaces, inversão de controle,
refatoração, testes unitários
automatizados, código limpo e
inúmeras outras práticas técnicas
que nos ajudam a construir um
software melhor.

O software sempre será limitado pelo hardware.
Mas limitar um software por um hardware
específico é como limitar um algoritmo por uma
linguagem de programação específica.

É ASSIM QUE EU
TRABALHO, CARA!
VOCÊ TEM QUE
MUDAR SEU
ALGORITMO PARA SE
AJUSTAR À MINHA
IMPLEMENTAÇÃO!
LINGUAGEM DE
PROGRAMAÇÃO

Diz que trabalha com microsserviços
Mas faz um sistema usando só uma
linguagem de programação!
Que microsserviço é esse?

MAIS UM MICROSSERVIÇO QUE
PODERIA TER SIDO
IMPLEMENTADO EM PHP, MAS
FOI FEITO NA MESMA
LINGUAGEM DO
SISTEMA TODO

PENSE
NISSO!

Como se tornar dependente
A arquitetura do
sistema é descrita
em termos de
níveis mais
elevados de
abstração

●
A arquitetura do sistema envolve a definição de
hardware.
●
Essa definição deve se referir à função de
hardware e não a uma marca de um
determinado fornecedor.

●
Na nuvem, esse problema parece inexistente,
porque você não “vê” o hardware.
●
Aí surge outro problema: o software de
infraestrutura, que opera como um hardware
virtual.
SOU QUASE
UM
HARDWARE!

É ASSIM QUE EU
TRABALHO, CARA!
VOCÊ TEM QUE
MUDAR SUA
APLICAÇÃO PARA SE
AJUSTAR AO MEU
AMBIENTE!
PROVEDOR DE
NUVEM

TENHO
SERVIÇOS E
COMPONENTES
QUE VÃO DEIXAR
SUA APLICAÇÃO
MUITO LOUCA,
CARA!
PROVEDOR DE
NUVEM
E me deixar
louco de
raiva?

VOCÊ USA COMPONENTES INADEQUADOS OU DE FORMA INADEQUADA?

VOCÊ ENTENDEU REALMENTE O DESIGN PATTERN ADAPTER?

ESTE COMPONENTE PELO MENOS TEM FRACO ACOPLAMENTO...

O SEU CÓDIGO É EMERGENCIAL?
Precisamos fazer
uma GRANDE
mudança
IMEDIATAMENTE!
Preciso fazer
um código que
funcione
LOGO!

O CENÁRIO É ESTE:
●
Você precisa implementar rápido
●
Não dá tempo de aplicar a melhor solução
●
Não dá tempo de achar alguém que
implementou a melhor solução.
●
A equipe trabalha sobre o Princípio
Scooby-Doo.

VOU FAZER DE
QUALQUER JEITO
AGORA, DEPOIS EU
MELHORO.
NUNCA VAI
MELHORAR!

Invertendo a dependência com vigor
●
Você pode criar um componente incompleto.
●
Só precisa prepará-lo para crescer.

●
Pense no futuro!
●
Cidades e código-fonte crescem!

Hoje você não precisa traduzir sua aplicação.
Mas e amanhã?
Ninguém pediu ainda, então não posso perder tempo fazendo algo que
não me pagaram pra fazer.
Você pode criar uma função ou método para tradução... que apenas
devolva o que recebeu.
Isso evitará que no futuro você tenha de alterar dezenas (ou centenas)
de arquivos para dar suporte à tradução.
E quando implementar essa função ou método… não acople ela
fortemente a nada!

Crie código extensível.
Permita que alguém conclua sua obra.

Faça seu software conversar com outros.
Use protocolos de comunicação compreensíveis por outros
componentes e aplicações, preferencialmente abertos.
EVITE IMPLEMENTAÇÕES EXCLUSIVAS DE UM
FORNECEDOR!
No caso de PHP, faça com que seus componentes possam
utilizar ou ser utilizados por outros componentes PHP
facilmente.

NÃO CRIE LAÇOS!
SUA APLICAÇÃO
COMPONENTE
DE TERCEIRO 1
COMPONENTE
DE TERCEIRO 2
COMPONENTE
DE TERCEIRO 3
FORTE ACOPLAMENTO

NÃO CRIE LAÇOS!
SUA APLICAÇÃO
COMPONENTE
DE TERCEIRO 1
COMPONENTE
DE TERCEIRO 2
COMPONENTE
DE TERCEIRO 3

NÃO CRIE LAÇOS!
SUA APLICAÇÃO
COMPONENTE
DE TERCEIRO 1
COMPONENTE
DE TERCEIRO 2
COMPONENTE
DE TERCEIRO 3
CAMADA DE INTEGRAÇÃO

Cuidado com frameworks!
“Frameworkitis é a doença que um framework quer fazer
muito por você ou faz de uma forma que você não quer, mas
você não pode mudar. É divertido obter toda essa
funcionalidade de graça, mas dói quando a funcionalidade
gratuita atrapalha. Mas agora você está preso ao framework.
Para obter o comportamento desejado, você começa a lutar
contra o framework. E nesse ponto você geralmente começa
a perder, porque é difícil dobrar o framework em uma direção
que ele não antecipou.”
ERICH GAMMA http://www.artima.com/lejava/articles/reuseP.html

MVC: O Ponto Crítico dos Frameworks
A implementação do architecture pattern MVC (Model
View Controller) geralmente é a que tem o maior conjunto
de acoplamentos.

Ao optar por uma implementação MVC específica,
estamos assinando um contrato com várias cláusulas de
obrigação, para usufruir de benefícios oferecidos por ela.

Procure uma implementação flexível, configurável, que
permita injeção de dependências, para que você possa
trocar implementações custosas por alternativas mais
leves (ou ter a possibilidade de obliterar processos).

A implementação MVC não pode ser um televisor que não
funciona sem controle remoto!

A implementação MVC deve permitir que você escolha os
componentes que realmente precisa.
Ela deve ser capaz de não fazer nada além do
necessário.

E o que o SOLID
tem a ver com isso?

E o que o SOLID
tem a ver com isso?
“O princípio de inversão de dependências [a letra D do
SOLID] diz respeito à depender de uma abstração e
não de uma implementação. Nesse caso, todos os
demais princípios são aplicados, garantindo que os
sistemas sejam o mais desacoplados e coesos possível”.
MAGNO SANTOS, citando ROBERT CECIL MARTIN

E o que o SOLID
tem a ver com isso?
Esse princípio deriva da orientação de Erich Gamma e
seus incríveis amigos no livro Design Patterns:
Programe para uma interface, não para uma
implementação.

D de SOLID: Reduzindo o vendor lock-in em aplicações PHP

Mais conteúdo relacionado

Semelhante a D de SOLID: Reduzindo o vendor lock-in em aplicações PHP

Mais de Flávio Lisboa

D de SOLID: Reduzindo o vendor lock-in em aplicações PHP