Oui - Je ne suis pas du tout un pro de Qt mais il me semble que de nombreux services et ressources comme le presse-papiers, les paramètres, le pool de threads ou les polices sont accessibles globalement . Vous avez aussi l’écran, le clavier, la souris et les périphériques d’entrée-sortie qui sont également accessibles globalement via des classes qui centralisent leur gestion et fournissent des accès unifiés aux événements et aux ressources associées.
La majorité des environnements OO utilisent des objets globaux qui représentent l’application ou le système, souvent pour structurer l’environnement d’exécution ou centraliser la gestion des ressources.
En Objective-C vous avez UIApplication sur iOS, en Swift @main struct App et UIApplication.shared, en Java la classe Application sous Android ou des singletons système comme Runtime.getRuntime(), en C# avec Application sous Windows Forms ou App sous WPF, en Python via certains frameworks comme Flask ou Django avec des instances globales d’application, ou en Delphi avec l’objet Application global…
➜ Ces objets servent de point d’entrée ou de gestionnaire centralisé pour l’environnement d’exécution et on obtient ces instances globales en les créant dans main() car elles sont rendues disponibles via des getters statiques / à travers l’objet Application.
Donc une ou des instances globales qui représentent le système sont acceptables et acceptées dans l’industrie comme une pratique courante.
Appliquez cela à la programmation embarquée, notamment sur Arduino : l’utilisation d’instances globales n’est pas forcément une mauvaise pratique ni un archaïsme, cela peut être un choix réfléchi et adapté au contexte.
Contrairement aux environnements généralistes où la modularité et la réutilisabilité imposent de limiter les variables globales, un microcontrôleur exécute une tâche dédiée, dans un cadre strict de ressources mémoire et de puissance de calcul.
Déclarer les instances en global permet d’allouer leur mémoire à la compilation, dans une zone bien définie (la zone data ou bss selon qu’elles sont initialisées ou non). Cela garantit qu’au démarrage, la mémoire occupée par ces objets est connue et réservée, évitant ainsi toute fragmentation dynamique et limitant les risques d’épuisement du tas ou de débordement de pile.
Il faut aussi se souvenir que l'allocation dynamique est souvent coûteuse et risquée dans ces environnements (pas de try catch sur un petit arduino), et permet une initialisation dès le démarrage, avec une empreinte fixe et maîtrisée, reportée à la compilation, ce qui facilite le dimensionnement mémoire.
C’est pour moi la même logique qu’un QApplication ou QGuiApplication sous Qt qui, de manière globale et centralisée, représente l’état de l’application. Ici, si vous pilotez des volets, l’état de chaque volet est central dans le système. Les instancier globalement permet à toutes les parties du programme d’y accéder sans surcharge inutile, et de maintenir un modèle mémoire parfaitement prévisible, ce qui est aussi fondamental en embarqué.