# Aspect théorique

Les données de configuration sont transmis au constructeur de `Zend_Config` sous la forme d'un tableau associatif, qui peut être multidimensionnel, afin de supporter une organisation des données du général vers le spécifique. Les classes d'adaptateur concrètes permettent de construire le tableau associatif pour le constructeur de `Zend_Config` à partir du système de stockage des données de configuration. Dans certaines utilisations spécifiques, les scripts de l'utilisateur peuvent fournir de tels tableaux directement au constructeur de `Zend_Config`, sans employer une classe d'adaptateur.

Chaque valeur du tableau de données de configuration devient une propriété de l'objet `Zend_Config`. La clé est utilisée comme nom de propriété. Si une valeur est un tableau, alors la propriété d'objet résultante est créée comme un nouveau objet `Zend_Config`, chargé avec les données du tableau. Cela se déroule récursivement, tel qu'une hiérarchie de données de configuration peut être créée avec n'importe quel nombre de niveaux.

`Zend_Config` implémente les interfaces Countable et Iterator afin de faciliter l'accès simple aux données de configuration. Ainsi, on peut employer la fonction `count()` et des constructions de PHP telles que foreach sur des objets `Zend_Config`.

Par défaut, les données de configuration fournies par `Zend_Config` ne sont pas modifiables (lecture seule), et une affectation (par exemple, `$config->database->host = 'example.com';`) lèvera une exception. Ce comportement par défaut peut cependant être surchargé par le constructeur pour permettre la modification des valeurs de données. De plus, quand les modifications sont autorisées, `Zend_Config` supporte l'effacement de valeurs (c'est-à-dire `unset($config->database->host)`). La méthode `readOnly()` peut être utilisée pour déterminer si les modifications sont autorisés pour un objet `Zend_Config` donné et la méthode `setReadOnly()` peut être utilisée pour empêcher toute nouvelle modification d'un objet `Zend_Config` qui aurait été créé en autorisant le modifications.

Il est important de ne pas confondre des modifications en cours de script avec l'enregistrement des données de configuration dans le support de stockage spécifique. Les outils pour créer et modifier des données de configuration pour différents supports de stockage ne concernent pas `Zend_Config`. Des solutions tiers open-source sont facilement disponibles afin de créer et / ou de modifier les données de configuration pour différents supports de stockage.

Les classes d'adaptateur héritent de la classe de `Zend_Config` ce qui permet d'utiliser ses fonctionnalités.

La famille des classes `Zend_Config` permet d'organiser les données de configuration en sections. Les classes d'adaptateur `Zend_Config` peuvent être chargées en spécifiant une section unique, des sections multiples, ou toutes les sections (si aucune n'est indiquée).

Les classes d'adaptateurs `Zend_Config` supporte un modèle d'héritage simple qui permet à des données de configuration d'être héritées d'une section de données de configuration dans d'autres. Ceci afin de réduire ou d'éliminer le besoin de reproduire des données de configuration pour différents cas. Une section qui hérite peut également surchargée les valeurs dont elle hérite de sa section parente. Comme l'héritage des classes PHP, une section peut hériter d'une section parent, qui peut hériter d'une section grand-parent, et ainsi de suite, mais l'héritage multiple (c.-à-d., la section C héritant directement des sections parents A et B) n'est pas supporté.

Si vous avez deux objets `Zend_Config`, vous pouvez les fusionner en un objet unique en utilisant la fonction `merge()`. Par exemple, prenons `$config` et `$localConfig`, vous pouvez fusionner `$localConfig` dans `$config` en utilisant `$config->merge($localConfig);`. Les éléments de `$localConfig` surchargeront les éléments nommés de la même manière dans `$config`.

L'objet `Zend_Config` qui réalise la fusion doit avoir été construit en autorisant les modifications, en fournissant `TRUE` en tant que second paramètre du constructeur. La méthode `setReadOnly()` peut être utilisée pour empêcher toute nouvelle modification après la fin de la fusion.