A palestra aborda a combinação de componentes de diferentes frameworks em uma aplicação, enfatizando a importância da manutenção e interoperabilidade do software. O apresentador, Flávio Gomes, discute padrões de construção de componentes e oferece exemplos práticos visando permitir que o código seja extensível e adaptável a mudanças futuras. A mensagem central é a necessidade de focar em soluções que facilitem a comunicação entre diferentes componentes, evitando amarras desnecessárias dos frameworks.

1. Componentes Transformers:
combinando o melhor
de cada framework
Flávio Gomes da Silva Lisboa
www.fgsl.eti.br

2. http://phptranslationfestbrasil.github.io/

3. Quem sou eu?
● Chefe do setor de adequação do ExpressoV3 em Curitiba

4. Quem sou eu?

5. FISL LATINOWARE
Quem sou eu?
● Fui palestrante e instrutor em vários eventos

6. Quem sou eu?
● Leciono a disciplina Programação PHP Orientada a Objetos
com Testes Unitários no curso de especialização em
Desenvolvimento de Aplicações Web na UniCesumar.

7. Quem sou eu?
● Sou autor dos livros:

8. http://romocavaleirodoespaco.blogspot.com.br

9. Resumo
Nesta palestra iremos aprender como combinar
componentes de diferentes frameworks dentro
de uma mesma aplicação sem criar problemas
de manutenção

10. Dúvida
Você vai falar sobre como combinar
frameworks, enquanto tem um cara falando
sobre um futuro sem frameworks?
Frameworks...
¡No más!

11. Esclarecimento
Não é porque algo parece não funcionar direito
que você tem de desistir de usar.

12. Conselho
Seja o cara que sabe usar os recursos que tem.

13. Descrição
Inicialmente trataremos sobre padrões de
construção de componentes, para então falar
sobre interoperabilidade entre aplicações PHP
e bibliotecas de componentes interoperáveis.
Finalmente mostraremos exemplos de
combinações de componentes de diferentes
frameworks.

14. 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.

15. 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.

16. Com que seu código parece?
Uso de componentes inadequados?

17. Com que seu código parece?
Não entendeu o design pattern Adapter?

18. Com que seu código parece?
Este pelo menos tem fraco acoplamento...

19. Código Emergencial
Precisamos fazer
uma GRANDE
mudança
IMEDIATAMENTE!
Preciso fazer um
código que
funcione LOGO!

20. Cenário
Fatos:
● 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.
Tartaglia Cardano

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

22. Padrões de Construção de
Componentes
Você pode criar um componente incompleto.
Só precisa prepará-lo para crescer.

23. Padrões de Construção de
Componentes
Pense no futuro!
Só precisa prepará-lo para crescer.

24. Padrões de Construção de
Componentes
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.

25. Padrões de Construção de
Componentes
Crie código extensível.
Permita que alguém conclua sua obra.

26. Interoperabilidade
Faça seu software conversar com outros.
Use protocolos de comunicação compreensíveis
por outras aplicações, preferencialmente
abertos.
No caso de PHP, faça com que seus
componentes possam utilizar ou ser utilizados
por outros componentes PHP facilmente.

27. Interoperabilidade
●Como encontrar classes
●Como escrever código
●Como tratar log

28. Interoperabilidade

29. Combinações de Componentes
Isto é um pleonasmo...
Componentes existem para serem combinados

30. Combinações de Componentes
Não basta ter as peças. Você precisa aprender a
ser um Mestre Construtor.

31. Frameworks
Frameworks contém componentes.
Diferentes frameworks tem diferentes
componentes para os mesmos propósitos.
É possível combinar componentes de
frameworks diferentes, desde que eles sejam
interoperáveis.

33. Componentes Desacoplados

34. DEVASTATOR

35. FRAMEWORK FULL STACK

36. DEVASTATOR
SUPERION

37. FRAMEWORK FULL STACK
FRAMEWORK FULL STACK

38. DEVASTATOR
SLUDGE
SWOOP
GRIMLOCK
SNARL SLAG

39. FRAMEWORK FULL STACK
MICROFRAMEWORK
MICROFRAMEWORK
MICROFRAMEWORK
MICROFRAMEWORK MICROFRAMEWORK

40. Frameworkities
A Doença dos Frameworks
“Frameworkitis is the disease that a framework wants to do
too much for you or it does it in a way that you don't want
but you can't change it. It's fun to get all this functionality for
free, but it hurts when the free functionality gets in the way. But
you are now tied into the framework. To get the desired
behavior you start to fight against the framework. And at
this point you often start to lose, because it's difficult to bend
the framework in a direction it didn't anticipate.”
Erich Gamma
http://www.artima.com/lejava/articles/reuseP.html

41. Cuidado ao
entregar o
controle!

42. 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.

43. MVC:
O Ponto Crítico dos Frameworks
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.

44. MVC:
O Ponto Crítico dos Frameworks
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).

45. MVC:
O Ponto Crítico dos Frameworks
A implementação MVC não pode ser um
televisor que não funciona sem controle remoto!

46. MVC:
O Ponto Crítico dos Frameworks
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.

47. MVC:
O Ponto Crítico dos Frameworks
● Cuidado com as unidades de reuso dos
frameworks!
● Bundles e modules, por exemplo, são
reusáveis diretamente apenas por seus
respectivos gerenciadores (Symfony, Zend).
● Bibliotecas são mais reutilizáveis que
estruturas modulares de implementações
MVC!

48. Orquestre componentes!

49. Escolha o mais adequado para
cada problema!

50. Use Composer para harmonizar
dependências!

51. Use Composer para harmonizar
dependências!
{
"require": {
"monolog/monolog": "1.0.*"
}
}

52. Não crie laços!
CAMADAS DE SUA APLICAÇÃO
FRAMEWORK 1 FRAMEWORK 2 FRAMEWORK 3

53. Não crie laços!
CAMADAS DE SUA APLICAÇÃO
X
FRAMEWORK 1 FRAMEWORK 2 FRAMEWORK 3

54. Não crie laços!
CAMADAS DE SUA APLICAÇÃO
API CENTRAL DE SUA APLICAÇÃO
FRAMEWORK 1 FRAMEWORK 2 FRAMEWORK 3

55. Não crie laços!
CAMADAS DE SUA APLICAÇÃO
API CENTRAL DE SUA APLICAÇÃO
FRAMEWORK 1 FRAMEWORK 2 FXRAMEWORK 3

56. Não crie laços!
CAMADAS DE SUA APLICAÇÃO
API CENTRAL DE SUA APLICAÇÃO
FRAMEWORK 1 FRAMEWORK 2 FRAMEWORK 4

57. Perguntas?

58. www.fgsl.eti.br