Nous écrivons de nombreuses applications Python qui nécessitent une personnalisation via des propriétés externes ou des applications pour lesquelles nous souhaitons personnaliser ou affecter le comportement avec des propriétés non codées en dur et/ou des propriétés de configuration d'exécution. Diverses recherches de solutions sur Google génèrent des didacticiels qui nous orientent vers des exemples de code qui, bien que fonctionnant pratiquement, ne s'adaptent pas de manière appropriée aux applications du monde réel.
Cet ensemble d'articles documente mon parcours à travers diverses implémentations alors que j'ai refactorisé et réimplémenté à plusieurs reprises tout au long de mon parcours vers un mécanisme simple, maintenable et facilement extensible pour gérer les propriétés de configuration des applications.
Les versions du didacticiel que j'ai trouvées étaient simplement des extensions des extraits de code fournis par les développeurs de bibliothèques pour prouver que leurs implémentations fonctionnent. Bien que cela soit suffisant pour fournir une preuve de concept, ces extraits ne sont pas adaptés au monde réel de l'application.
Un exemple de ceci est l'extrait de code suivant.
import configparser def create_config(): config = configparser.ConfigParser() # Add sections and key-value pairs config['General'] = { 'debug': 'True', 'log_level': 'info' } config['Database'] = { 'db_name': 'example_db', 'db_host': 'localhost', 'db_port': '5432' } with open('config.ini', 'w') as configfile: config.write(configfile) if __name__ == "__main__": create_config()
Bien que cet extrait de code nous permette certainement de conserver nos valeurs de configuration, il nous laisse avec le problème de la lecture de ces valeurs persistantes. Encore une fois, les extraits de code du développeur d'implémentation nous fournissent un exemple de code sur la façon de récupérer ces valeurs, comme illustré dans les extraits de code suivants.
import configparser def read_config(): config = configparser.ConfigParser() config.read('config.ini') # Access values from the configuration file debug_mode = config.getboolean('General', 'debug') log_level = config.get('General', 'log_level') db_name = config.get('Database', 'db_name') db_host = config.get('Database', 'db_host') db_port = config.get('Database', 'db_port') # Return a dictionary with the retrieved values config_values = { 'debug_mode': debug_mode, 'log_level': log_level, 'db_name': db_name, 'db_host': db_host, 'db_port': db_port } return config_values if __name__ == "__main__": # Call the function to read the configuration file config_data = read_config() # Print the retrieved values print('Debug Mode', config_data['debug_mode']) print('Log Level', config_data['log_level']) print('Database Name', config_data['db_name']) print('Database Host', config_data['db_host']) print('Database Port', config_data['db_port'])
Je vois de nombreux problèmes dans le code ci-dessus. Bien que cela soit parfaitement acceptable pour les petits scripts, le code souffre de l'utilisation de valeurs de chaîne, liées aux noms de variables Python réels et de leur prolifération potentielle dans une grande base de code. Bien que cela soit potentiellement atténué par l'utilisation de constantes globales, mon avis est que cela n'est pas évolutif car il ne suit pas un principe de conception de logiciel de base adopté par Andrew Hunt et David Thomas, dans leur livre fondateur, The Pragmatic Programmer et échoue au DRY. principe, alias Ne vous répétez pas.
Le code source de cet article est ici.
Voir mon prochain article qui documente une mise en œuvre initiale pour résoudre certains des problèmes que j'ai évoqués.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!