Maison > Article > développement back-end > Refactoring des méthodes PHP multi-paramètres (exemple de code)
Supposons que nous voulions compléter une fonction de sauvegarde d'articles. Si nous utilisons la programmation fonctionnelle, cela ressemblera probablement à ceci :
<?php function saveArticle($title, $content, $categoryId) { // ... } ?>
Chaque paramètre représente un attribut, mais cela pose un problème. La liste peut être très longue. À l'heure actuelle, ce serait une bonne idée d'utiliser la technologie de programmation objet :
<?php class Article { var $title; var $content; var $categoryId; function save() { // ... } } ?>
Ici, les paramètres de la méthode d'origine sont convertis en attributs de l'objet, réduisant ainsi considérablement le nombre de paramètres de la méthode. La plupart du temps, cette méthode est bonne, mais tous les paramètres ne sont pas aptes à exister sous forme d'attributs d'objet. Le principe de différenciation est de voir si ces paramètres appartiennent aux attributs intrinsèques ou aux caractéristiques externes de l'objet. Si elles ne sont pas distinguées, elles seront toutes converties en propriétés d'objet, ce qui rendrait l'objet lui-même dénué de sens.
Par exemple, notre objet Article a également une méthode appelée find Lors de son utilisation, des paramètres tels que la limite, le décalage, l'ordre, etc. peuvent être impliqués :
<?php class Article { var $title; var $content; var $categoryId; var $limit = 10; var $offset = 0; var $order = 'created DESC'; function save() { // ... } function find($categoryId) { // ... } } ?>
Comme le montre ci-dessus. qu'une fois que nous convertissons des paramètres tels que la limite, le décalage et l'ordre en attributs de l'objet, l'objet lui-même devient indescriptible, car bien que le titre, le contenu et l'identifiant de catégorie puissent être comptés comme des attributs intrinsèques de l'objet, la limite, le décalage et l'ordre sont non. Non, tout au plus cela ne peut-il être considéré que comme une caractéristique externe. Le résultat de ne pas les distinguer est fondamentalement le début d'un cauchemar. Par conséquent, il est préférable de mettre honnêtement les caractéristiques externes dans les paramètres de la méthode (plus strictement parlant, la méthode find doit être une méthode de type statique, mais le texte est une explication simple, pas besoin d'entrer dans les détails) :
<?php class Article { var $title; var $content; var $categoryId; function save() { // ... } function find($categoryId, $limit = 10, $offset = 0, $order = 'created DESC') { // ... } } ?> 可惜如此一来又出现了文章开头所说的问题,find方法的参数太多了,缺乏可读性,所以还得重构: <?php class Article { var $title; var $content; var $categoryId; function save() { // ... } function find($categoryId, $options = array()) { $default = array( 'limit' => 10, 'offset' => 0, 'order' => 'created DESC' ); $options = array_merge($default, (array)$options); // ... } } ?>
Ça a l'air plutôt bien. Vous pouvez utiliser une méthode similaire à la suivante lors de l'appel :
$article->find(123, array('limit' => 20));
En termes simples, il utilise des paramètres de tableau pour simuler un effet similaire aux paramètres de mots-clés. De cette manière, la fonction des paramètres peut être décrite à travers les noms de clés du tableau, augmentant ainsi la lisibilité du code. Les méthodes de refactoring comme celle-ci sont largement utilisées dans des projets tels que CakePHP. Si vous les comprenez bien, vous pouvez instinctivement écrire du code hautement lisible lors de l'écriture de code à l'avenir.
Supplémentaire : par rapport à array_merge, utiliser $options += $default est également un bon choix ; De plus, si la logique des options est très complexe, vous pouvez également utiliser un tableau au lieu d'un tableau pour encapsuler les opérations logiques à l'aide d'un objet spécial.
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!