L’un des arguments principaux justifiant le recours à un framework (par exemple, au hasard, Symfony), contrebalançant le fait qu’il est un peu « lourd », est que puisqu’il prend en charge un grand nombre des tâches répétitives de bas niveau, il évite au développeur d’avoir, selon l’expression consacrée, à réinventer la roue à chaque fois qu’il entame une nouvelle application ou une nouvelle interface.
Résumé de l’épisode précédent : un framework, c’est une boîte à outils, des briques de base, et une méthodologie pour développer mieux, plus vite, et de manière plus sûre (un peu comme ça, quoi). Mais si ça peut fortement aider, ça n’est pas magique, et ça demande de suivre les principes du framework lui-même.
Une partie des principes méthodologiques qui va avec un framework est couramment regroupée sous le nom de design patterns. Une fois encore, on s’abstiendra de traduire l’expression (la version française préconisée étant patrons de conception, et ça sonne un peu Bergère de France…)
