Framework: você REALMENTE sabe o que é isto?
Tags: frameworks, aprendizado, braziliandevs
Published: 2020-01-06 13:22:45

---
title: Framework: você REALMENTE sabe o que é isto?
published: true
date: 2018-06-18 02:53:59 UTC
tags: frameworks, aprendizado, braziliandevs
cover_image: https://i0.wp.com/www.itexto.com.br/devkico/wp-content/uploads/2018/06/framework.jpg?w=800&ssl=1
---
Recentemente retomei meu contato com o <a href="http://angular.io">Angular</a>: está sendo uma experiência muito enriquecedora pois a imagem negativa que tinha da ferramenta recebeu um significativo upgrade. Li uns 90% de toda a sua documentação oficial (incluindo este <a href="https://www.manning.com/books/angularjs-in-action">livro incrível</a>) e o que posso dizer é: que&nbsp;<strong>framework&nbsp;</strong>maravilhoso! Mas o que é um framework?
<h2>Um post atrasado no mínimo uma década</h2>
Meu primeiro contato com o termo "framework" foi quando comecei a aprender Java. Naquela época (1996, 97, bem mais em 2001, 2002) muito se falava a respeito de frameworks, especialmente após o lançamento do <a href="http://struts.apache.org">Struts</a>.&nbsp; Confesso que não conseguia entender direito o significado do termo, e não é pra menos. Vejam o que me diziam na época a respeito:
<ul>
 	<li>"Framework é uma aplicação pré-pronta".</li>
 	<li>"É um conjunto de códigos que você pode reaproveitar em seus projetos e que te poupa muito tempo".</li>
 	<li>"É uma solução pré-pronta para problemas recorrentes".</li>
</ul>
Mas e uma <strong><em>"biblioteca"</em></strong>? Ela também não é um conjunto de códigos pré-prontos que eu posso reutilizar?

Se existem estas duas palavras:&nbsp;<em>biblioteca</em> e&nbsp;<em>framework</em>, seriam estas sinônimos? Se sim, por que veio depois este termo, framework? Será que eu o descobri posteriormente e que o mesmo sempre existiu (sim)?

Não são sinônimos e hoje, após trabalhar com diversos sistemas que não foram escritos por mim posso dizer algo com plena segurança:&nbsp;<strong>boa parte do software que temos dificuldade em manter hoje é mal escrito devido à má compreensão do termo "framework".</strong>
<h2>O que é uma biblioteca?</h2>
<img class="aligncenter size-full wp-image-2763" src="http://www.itexto.net/devkico/wp-content/uploads/2018/06/biblioteca.jpg" alt="" width="500" height="223">

Primeiro é importante saber aquilo com o qual as pessoas costumam confundir o framework: a biblioteca. Esta sim é um conjunto de códigos reutilizáveis que vão se apresentar sob a forma de funções, classes, módulos...

<strong>Seu código invoca</strong> sua execução e como consequência o trabalho pesado é realizado para você. Vamos a alguns exemplos práticos. O código a seguir, escrito em Java (extraído <a href="https://www.mkyong.com/java/how-to-compress-files-in-zip-format/">daqui</a>) usa as bibliotecas de compressão da linguagem para gerar um arquivo zip.

[code language="java"]
package com.mkyong.zip;

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.util.zip.ZipEntry;
import java.util.zip.ZipOutputStream;

public class App
{
public static void main( String[] args )
{
byte[] buffer = new byte[1024];

try{

FileOutputStream fos = new FileOutputStream("C:\\MyFile.zip");
ZipOutputStream zos = new ZipOutputStream(fos);
ZipEntry ze= new ZipEntry("spy.log");
zos.putNextEntry(ze);
FileInputStream in = new FileInputStream("C:\\spy.log");

int len;
while ((len = in.read(buffer)) &gt; 0) {
zos.write(buffer, 0, len);
}

in.close();
zos.closeEntry();

//remember close it
zos.close();

System.out.println("Done");

}catch(IOException ex){
ex.printStackTrace();
}
}
}
[/code]

<em>FileOutputStream, ZipOutputStream, ZipEntry, FIleInputStream</em> são classes disponibilizadas pela&nbsp;<strong>biblioteca padrão do Java SE</strong>. Observe algo interessante: eu simplesmente as importo e, na sequência,&nbsp;<strong>meu código define quando estas serão executadas e como</strong>.

É possível criar novas sub-classes baseadas nestas que acabei de mencionar, entretanto alguns aspectos se mantém:
<ul>
 	<li>Estou usando código pré-existente que não foi escrito por mim.</li>
 	<li>Meu código está definindo quando usarei estas classes/funções.</li>
</ul>
Outro exemplo bem simples podemos ver no código C escrito a seguir:

[code language="c"]

#include &lt;stdio.h&gt;

int main(void) {
printf("Aqui de buenas usando a função printf");
return 0;
}

[/code]

Agora ao invés de classes estou importando a biblioteca de I/O clássica da linguagem C e, na sequência, reaproveito a função <strong>printf</strong>, disponibilizada por esta. E novamente o fluxo do meu programa é definido inteiramente por mim:&nbsp;<em>imprima este texto inútil e na sequência retorne 0</em>.
<blockquote>Então vamos à definição Kiconiana de uma biblioteca:&nbsp;<em>código escrito por terceiros focando o reuso e cuja ordem de execução é definida inteiramente por você.</em></blockquote>
<h2>E o framework, o que é?</h2>
É uma aplicação semi pronta? Sim, mas esta é uma definição muito vazia (bibliotecas também podem ser consideradas como tal). É um conjunto de código que posso reaproveitar? Óbvio, mas também é uma descrição incompleta e ainda gera confusão em relação ao termo&nbsp;<em>biblioteca</em>. É uma solução para um problema recorrente? Também. <strong>Então, qual a diferença?</strong>

O significado fica mais claro quando pensamos na tradução do termo para o português: <em>framework </em>pode ser traduzido como&nbsp;<em>moldura</em>,&nbsp;<em>armação</em>. Imagens surgem em minha mente:

[caption id="attachment_2767" align="aligncenter" width="600"]<img class="size-full wp-image-2767" src="http://www.itexto.net/devkico/wp-content/uploads/2018/06/moldura.jpg" alt="" width="600" height="600"> isto é uma moldura[/caption]

[caption id="attachment_2768" align="aligncenter" width="608"]<img class="size-full wp-image-2768" src="http://www.itexto.net/devkico/wp-content/uploads/2018/06/vigamento.jpeg" alt="" width="608" height="420"> Isto é um vigamento, que também é chamado de armação[/caption]

[caption id="attachment_2769" align="aligncenter" width="292"]<img class="size-full wp-image-2769" src="http://www.itexto.net/devkico/wp-content/uploads/2018/06/armacao.jpeg" alt="" width="292" height="292"> e esta é uma armação de óculos[/caption]

Armação, vigamento e moldura: o que tem em comum? Me lembro de ficar um bom tempo me questionando a respeito.&nbsp;<em>Framework: por que este termo? O que isto tem a ver com moldura???</em>

A moldura existe para suportar a gravura/imagem, o vigamento para que as telhas ou piso possam ser incluídos acima de si e a armação dos óculos fornece a estrutura necessária para que as lentes possam estar bem posicionadas em relação à nossa face. E o framework?

Enquanto no caso da biblioteca o ciclo de vida do nosso código é de nossa responsabilidade, ao lidamos com o framework o contrário ocorre: nós fornecemos a gravura para a moldura, o piso para o vigamento e as lentes para a armação.

Não somos nós que definimos&nbsp;<strong>quando</strong> nosso código executa: quem define isto é o framework. Se você já trabalhou com Spring ou Angular talvez isto lhe soe familiar. Lá vai: frameworks nada mais são que a aplicação mais básica do conceito de&nbsp;<a href="https://pt.wikipedia.org/wiki/Invers%C3%A3o_de_controle"><em>inversão de controle</em></a>.&nbsp; A propósito, o Martin Fowler tem <a href="https://www.martinfowler.com/bliki/InversionOfControl.html">um texto</a> muito bom sobre isto.

Vamos a um exemplo bem simples baseado em Angular? Imagine que eu queira escrever um componente: então escrevo algo similar ao código a seguir usando TypeScript:

[code lang="java"]

@Component({
selector: 'login',
templateUrl: './login.component.html',
styleUrls: ['./login.component.css']
})
export class LoginComponent implements OnInit {

credentials: Credentials;

constructor(private usuarioService: UsuarioService) {
this.credentials = new Credentials(null,null);
}

ngOnInit() {
}

entrar() {
this.usuarioService.auth(this.credentials);
}

}

[/code]

Aquela função ali,&nbsp;<em>ngOnInit</em>, não sou eu quem a invoco: é o Angular. Repare: apenas forneço os músculos para este esqueleto. Eu sei que aquele método será invocado, mas não por mim. Em momento algum escrevo código como o exemplo a seguir:

[code lang="java"]
usuarioService = new UsuarioService();
login = new LoginComponent(usuarioService);
login.ngOnInit();
[/code]

O código acima é aquele que tipicamente escrevemos ao lidar com bibliotecas. Mas o que ganhamos com esta delegação? Será que minha função realmente será chamada?

Lembra quando mencionei que sim, frameworks são soluções para problemas que ocorrem com frequência e que também são aplicações pré-prontas, mas que vão além? Pois bem: o problema que todo framework resolve é essencialmente o ciclo de vida do nosso código.

Autores de frameworks se preocupam com a vida de nossos objetos/funções: quando devem ser criados, usados e destruídos. E isto de uma forma ótima, garantindo que nosso trabalho consista apenas em fornecer o conteúdo necessário para que nossas&nbsp;<strong>necessidades de negócio&nbsp;</strong>sejam atendidas.

Vamos a mais um exemplo: desta vez usando a API Servlet do Java. Um Servlet pode ter diversas formas, a mais comum é o HTTP que tem como objetivo receber requisições pelo protocolo (HTTP), executar nossas regras e, finalmente, retornar conteúdo ao usuário final da aplicação. Vamos implementar um servlet?

[code language="java"]
package br.com.kicosoft;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ServletDemo1 extends HttpServlet{

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException{
PrintWriter out = response.getWriter();
out.println("&lt;html&gt;");
out.println("&lt;body&gt;");
out.println("
&lt;h1&gt;Sou um servlet feliz!&lt;/h1&gt;

");
out.println("&lt;/body&gt;");
out.println("&lt;/html&gt;");
}
}

[/code]

Primeiro eu escrevo a minha classe, que extenderá uma outra chamada HttpServlet. Meu papel consiste apenas em sobrescrever os métodos HTTP que me interessam, no caso,&nbsp;<em>doGet</em>, que corresponde ao método GET do protocolo. Minha função define o que deverá ser retornado ao usuário: o conteúdo HTML que você vê em meu código.

Repare na riqueza: não preciso me preocupar em implementar o protocolo HTTP, ou mesmo um algoritmo de espera (ocupada ou não) de requisições que chegam ao meu servidor. Apenas&nbsp;<strong>forneço ao meu framework<em>&nbsp;</em>o código que desejo ser executado.</strong>
<blockquote>Então, como posso definir um framework à moda Kiconiana? É o maestro responsável por orquestrar seu código visando resolver um ou mais problemas específicos .</blockquote>
O problema específico pode ser a construção de uma aplicação web, uma integração (pense em Apache Camel implementando os Enterprise Integration Patterns), um jogo (pense em um engine como o Unity). Seu papel é portanto apenas fornecer o código que será executado pelo framework. O que nos leva à grande questão.
<h2>Frameworks são burocráticos</h2>
<img class="aligncenter size-full wp-image-2775" src="http://www.itexto.net/devkico/wp-content/uploads/2018/06/burocracia.jpeg" alt="" width="800" height="465">

Lembra no início deste post quando disse que boa parte do código mal escrito que vemos hoje tem como principal problema o fato de haver uma má compreensão a respeito do termo "framework"? O problema nasce quando ignora-se este fato: frameworks são burocráticos.

O termo burocracia tem uma conotação bastante negativa mas é um fato necessário para que haja ordem, para que se consiga <strong>formalizar a identificação de elementos</strong>.

(Sabia que a escrita nasce de uma necessidade burocrática? Dica: pesquise sobre a origem da escrita cuneiforme e os sumérios.

Lembre: burocracia é uma coisa, burrocracia, outra.)

[caption id="attachment_2776" align="aligncenter" width="450"]<img class="size-full wp-image-2776" src="http://www.itexto.net/devkico/wp-content/uploads/2018/06/cuneiforme.jpeg" alt="" width="450" height="302"> A literatura nasce de um hacking da burocracia. Pense nisto![/caption]

Imagine que você irá escrever um framework: seu papel é orquestrar a execução de código de terceiros, certo? Como você o identifica este código e o papel a ser desempenhado por este? Alguma formalização precisa ser posta em prática, o que ocorrerá através da definição de padrões, tais como:
<ul>
 	<li>Presença de arquivos de configuração que identifique os artefatos. Lembra do XML no Java ou Spring?</li>
 	<li>Inclusão de anotações em nosso código. Olha ali o meu exemplo usando Angular e a anotação @Component.</li>
 	<li>A implementação de uma interface ou extensão de classes (lembra do meu Servlet?).</li>
 	<li>Padronizações no código como, por exemplo, a definição de nomes padrão para eventos de ciclo de vida dos objetos (já viu <a href="http://tapestry.apache.org">Tapestry</a>?).</li>
 	<li>Qualquer outro dispositivo que sirva para marcar o papel desempenhado pelo código a ser orquestrado.</li>
</ul>
O principal problema que encontro em código legado é justamente este: quem o evoluiu não se esforçou o suficiente para conhecer o framework adotado na escrita do projeto. E ainda pior: usou esta "moldura" como se fosse uma biblioteca, desrespeitando completamente o ciclo de vida proposto por esta.

Sabe aquele sujeito que sempre "dá um jeitinho" na burocracia cortando caminho? É o programador que usa o framework como biblioteca e ferra a gente no futuro.
<h2>Frameworks são limitados</h2>
<img class="aligncenter size-full wp-image-2777" src="http://www.itexto.net/devkico/wp-content/uploads/2018/06/limites.png" alt="" width="400" height="266">

Assim como o termo&nbsp;<em>burocracia</em>, a palavra&nbsp;<em>limitada</em> também tem uma conotação negativa em nossa sociedade, mas infelizmente é verdade: frameworks são limitados (e tem de ser). Aqui nasce outro problema que encontro em muito código legado.

Lembra que na definição Kiconiana menciono o fato do framework&nbsp;<em>visar resolver um ou mais problemas específicos?</em> Pois é: meu framework web favorito é o <a href="http://grails.org">Grails</a>, mas não o uso para implementar integrações.

Apesar de 90% do código que vejo ser escrito hoje visar resolver o problema da construção de aplicações web (ou web services, micro-serviços), este não é o único problema computacional a ser resolvido.

Talvez você precise escrever uma automação residencial (<a href="https://developer.apple.com/homekit/">HomeKit</a> da Apple), ou quem sabe uma integração (<a href="http://camel.apache.org">Apache Camel</a>), talvez seja a implementação de um jogo de tiro em primeira pessoa (<a href="https://www.cryengine.com/">Cry Engine</a>). Posso ficar um bom tempo aqui com exemplos.

O importante é: muitos dos problemas que encontro são resultantes da má escolha do framework para aplicações distintas do seu propósito original. Isto deve ser levado em consideração. Nem tudo é uma aplicação web, e desconfio de gente que diz ser capaz de resolver qualquer problema usando um único framework.

O que a armação, a moldura e o vigamento tem em comum? Eles <strong>limitam</strong> a forma do que irão orquestrar.
<h2>Concluindo</h2>
Estudando o Angular (6) fiquei maravilhado com o modo como ele organiza meu código fonte e orquestra a sua execução, o que me fez voltar ao conceito de framework e, na sequência, finalmente liberar este post.

Resumindo, digo que você deve evitar as seguintes armadilhas ao escrever seu código:
<ul>
 	<li>Saber se precisa realmente de um framework ou de uma biblioteca (em 95% das vezes usará os dois no mesmo projeto).</li>
 	<li>Saber como usar uma biblioteca e, principalmente, um framework.</li>
 	<li>Buscar entender as formalizações definidas pelos autores do seu framework (poderíamos falar o mesmo a respeito de bibliotecas: pense em OpenGL).</li>
 	<li>Entender para qual fim o framework foi escrito e usá-lo apenas para este fim.</li>
 	<li>Resumindo o resumo: você deve respeitar o framework.</li>
</ul>
Infelizmente (ou felizmente?) não se discute com tanta ênfase hoje o significado dos termos biblioteca e framework. Talvez pelo fato de terem se tornado ubíquos para nós com o passar do tempo, o que mostra termos evoluído (e muito) de lá pra cá.

Mais uma vez o <a href="https://pt.wikipedia.org/wiki/Ludwig_Wittgenstein">Wittgenstein</a> estava certo: a maior parte dos problemas surge da má compreensão da linguagem.

[caption id="attachment_1821" align="aligncenter" width="561"]<img class="size-full wp-image-1821" src="http://www.itexto.net/devkico/wp-content/uploads/2014/05/wittgenstein.jpg" alt="" width="561" height="319"> Ludwig Wittgenstein - 1889 - 1951[/caption]