Libraries vs. Frameworks – Qual é a diferença?

A página da Wikipédia para uma biblioteca de códigos define-a como:

“Na informática, uma biblioteca é uma colecção de recursos não voláteis utilizados por programas de computador, muitas vezes para o desenvolvimento de software. Estes podem incluir dados de configuração, documentação, dados de ajuda, modelos de mensagens, código pré-escrito e subrotinas, classes, valores ou especificações de tipo.”

Comparado com a definição de um framework:

“Na programação de computadores, um framework de software é uma abstração na qual o software que fornece funcionalidade genérica pode ser seletivamente alterado por código adicional escrito pelo usuário, fornecendo assim um software específico do aplicativo.

Provê uma forma padrão de construir e implementar aplicações e é um ambiente de software universal e reutilizável que fornece funcionalidade particular como parte de uma plataforma de software maior para facilitar o desenvolvimento de aplicações, produtos e soluções de software.”

Existe muito para desempacotar mas se você já trabalhou com ambos, você provavelmente já pode ver que, geralmente, uma biblioteca de código é usada para resolver um problema específico ou adicionar um recurso específico ao seu programa.

Um framework, por outro lado, fornece algo muito mais genérico e reutilizável. Se você continuar lendo a entrada da Wikipedia, você vai notar que três coisas separam um framework de uma biblioteca.

Inversão de controle

Libraries plug into your code, Your code plugs into a framework.

A primeira grande diferença entre um framework e uma biblioteca é quem está no controle do processo de desenvolvimento.

Com uma biblioteca de código, um desenvolvedor geralmente chama a biblioteca sempre que achar apropriado. Um framework geralmente requer que o desenvolvedor esteja totalmente imerso em seu fluxo de trabalho.

Como resultado, muitas vezes parece que o framework está no controle do processo de desenvolvimento e não o desenvolvedor. Isto é inversão de controle! Isto é normalmente simplificado como alguma variação do seguinte:

  • Library: Chame-nos para fazer o trabalho.
  • Framework: Você não nos chama, nós chamamos você.

É por causa desta inversão de controle que os frameworks são muito mais opinantes e também porque eles são capazes de fazer tanto pelos desenvolvedores.

Opinionado para aqueles que se perguntam significa que os frameworks estão tomando muitas decisões sobre como o código é escrito, a localização dos arquivos, e possivelmente até mesmo o nome dos referidos arquivos.

Making these assumptions allows for the usage of the paradigm of convention over configuration which allows developers to skip the process of app configuration in exchange for following certain conventions (such as putting certain files in certain folders, etc.).

Ruby on Rails is a popular framework for developing web applications.

Look at a framework like Ruby on Rails. It is often considered highly opinionated. Quando você cria um novo projeto com Ruby on Rails, ele irá gerar inúmeras pastas e arquivos com bastante código pré-escrito.

A maior parte do trabalho do desenvolvedor provavelmente será feita na pasta da aplicação (esta é a localização dos modelos, views, sub-pastas dos controladores) mas há muito outro código nesse projeto Rails que é projetado para fazer sua aplicação rodar.

Mais ainda, Ruby on Rails tem um fluxo de trabalho específico que ele espera que você siga. Quando você cria um modelo User no Rails, ele assume que está vinculado a um modelo UsersController.

Rails quer esses arquivos nomeados de uma certa forma (user.rb para o modelo e users_controller.rb para o controlador) e os quer em suas respectivas pastas.

Desviar-se do fluxo de trabalho do Rails o deixará frustrado em como e porque seu código não está funcionando. Work with it and everything just seems to magically work.

A large part of that magic (some do refer to it as Rails magic) is just all of that pre-written code working in the background. You fill in the models, views, controllers, and draw some routes, and Rails will take care of linking everything up correctly.

ChartJS lets you make some really beautiful charts.

Compare this to Chart.js which is a JavaScript library for creating really beautiful charts.

Você escolhe quando e onde chamar Chart.js e embora seja verdade que você é obrigado a preencher campos ao fazer um novo gráfico (você vai querer especificar o tipo de gráfico, etiquetas, cores, etc.) ele não controla seu fluxo de trabalho.

Chart.js só se preocupa com as informações necessárias para desenhar um gráfico; ele poderia se importar menos com o resto do seu código.

Extensibilidade

Um conceito importante na programação orientada a objetos é o princípio aberto-fechado. O princípio open-closed afirma que o comportamento do código deve ser aberto para ser alterado/extendido sem que ele tenha que ser diretamente alterado.

Um exemplo simples disso é a herança em classes que permite que uma subclasse adicione funcionalidades e recursos necessários a ela sem nunca precisar alterar diretamente o código na classe pai.

Extensibilidade permite que um desenvolvedor adicione novas funcionalidades a um framework ou adapte o comportamento das funcionalidades existentes para atender às suas necessidades sem modificar o código fonte.

Bom frameworks são construídos com extensibilidade em mente. Eles fornecem a funcionalidade genérica necessária para desenvolver uma aplicação genérica mas se deixam abertos para adições e mudanças específicas necessárias para uma aplicação específica.

Se um framework não fosse extensível, ele seria bastante limitado em sua funcionalidade e isso o tornaria muito menos atrativo para aprender.

Cuidado com os exemplos acima, existem várias extensões para o framework Ruby on Rails para adicionar recursos adicionais como autenticação de usuário.

Se o Rails não tivesse essas extensões, isso dificultaria severamente o que você poderia fazer usando-o. Para ser justo, Chart.js também tem muitos plugins e extensões. Estes permitem coisas como desenhar tipos adicionais de gráficos.

A diferença aqui é muito menos visível, entretanto, porque frameworks fornecem funcionalidades gerais, eles devem ser construídos com extensibilidade em mente para que funcionalidades específicas do aplicativo possam ser implementadas.

Uma biblioteca não precisa necessariamente ser construída com extensibilidade em mente, seu propósito principal é realizar uma tarefa específica.

Código não modificável

Este conceito é felizmente muito mais fácil e simples de explicar. A resposta curta e simples é que frameworks irão gerar um monte de código e, na maioria das vezes, você não toca nesse código.

Voltando ao Rails como explicado antes, geralmente, um desenvolvedor gasta a maior parte do seu tempo trabalhando na pasta do aplicativo. O desenvolvedor geralmente não irá alterar ou excluir o código.

pré-escrito.

Deixe um comentário