Accueil🇫🇷Chercher

God object

Un God object est, dans le domaine de la programmation orientée objet, un objet qui reconnaît trop de choses ou fait trop de choses. Le god object est un exemple d'antipattern (ou anti-patron).

Description

Le principe général de la programmation structurée est de s'attaquer à un problème important en le divisant en plus petits problèmes à résoudre (stratégie de diviser pour régner). Une fois chacun des petits problèmes résolus, le problème général est automatiquement réglé. Ainsi, il n'y a qu'un objet auquel il doit être connu ou renseigné : lui-même. De la même façon, il n'y a qu'un seul ensemble de problèmes auquel un objet doit se confronter : l'ensemble des siens propres.

La programmation « god object Â» ne suit pas cette approche. Au lieu de cela, la plus grande partie du programme consiste en un seul bloc qui est renseignĂ© sur tout et maintient constamment Ă  jour donnĂ©es ou informations sur le programme, et fournit la plupart des fonctions et des algorithmes qui utilisent ces donnĂ©es. Du fait que cet objet supporte et organise tellement d'informations Ă  lui seul, il joue un rĂ´le identique Ă  celui d'un dieu. Au lieu de blocs de programme communicant indĂ©pendamment entre eux et sans intermĂ©diaire, les autres parties du programme sont dĂ©pendants du god object pour communiquer et prendre leurs informations. Comme le god object est rĂ©fĂ©rencĂ© par tout le reste de la programmation, la maintenance de celle-ci devient très difficile, y compris dans les plus ordonnĂ©s des programmes.

Un god object est la version « orientĂ©e-objet Â» de l'incapacitĂ© Ă  concevoir correctement les sous-programmes dans un langage de programmation procĂ©dural, ou d'utiliser trop de variables globales pour y stocker des informations sur l'Ă©tat du programme Ă  un moment donnĂ© (comme les drapeaux).

Bien que la création d'un god object soit considérée comme une mauvaise pratique de programmation, cette technique est à l'occasion utilisée dans les environnements critiques de programmation (comme les microcontrôleurs), où le gain dans la vitesse d'exécution et la centralisation du contrôle sont des facteurs plus importants que la facilité de maintenance et l'élégance de la programmation.

Notes et références

Voir aussi

Bibliographie

  • (en) Arthur J. Riel, Object-Oriented Design Heuristics, Boston, MA, Addison-Wesley, , 8e Ă©d., 379 p., reliĂ© (ISBN 978-0-201-63385-6, LCCN 95048396), « Chapter 3: Topologies of Action-Oriented Vs. Object-Oriented Applications »

« 3.2: Do not create god classes/objects in your system. Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem. »

Liens externes

Cet article est issu de wikipedia. Text licence: CC BY-SA 4.0, Des conditions supplémentaires peuvent s’appliquer aux fichiers multimédias.