Trois principes de l'abstraction du code

Cet article est reproduit à partir du blog de Yifeng, le contenu original est le suivant.

Le développement de logiciels estPrincipe "abstrait"(Une incarnation de l'abstraction).

La soi-disant «abstraction» se réfère à l'extraction de modèles communs de problèmes spécifiques, puis en utilisant des solutions communes pour y faire face.

Lors du développement de logiciels, d'une part, nous voulons toujours utiliser le code que d'autres ont écrit, et d'autre part, nous voulons réutiliser le code que nous écrivons autant que possible afin de réduire la charge de travail. Pour atteindre les deux objectifs, cela nécessite de l'«abstraction».

Récemment, j'ai lu un article du programmeur américain Derrick Bailey sur les trois principes que "abstrait" devrait suivre.

Principes I. DRY

DRY IS AN ACRONYM FOR DON'T REPEAT YOURSELF, MEANING "DON'T REPEAT YOURSELF."

Le chef-d'œuvre de l'ingénierie logicielle The Pragmatic Programmer a d'abord proposé ce principe. Son implication est que chaque fonction du système devrait avoir une implémentation unique. Autrement dit, si vous rencontrez le même problème plusieurs fois, vous devez extraire une solution commune et ne pas développer la même fonctionnalité encore et encore.

Ce principe est parfois appelé le principe une fois et une seule fois.

Ii, Principes YAGNI

YAGNI est un acronyme pour Vous n'allez pas à elle, ce qui signifie "vous n'en aurez pas besoin."

C'est le principe préconisé par la « programmation extrême », qui se réfère à des fonctionnalités que vous pensez utiles, qui sont pratiquement inutiles. Par conséquent, toutes les autres fonctionnalités, à l'exception des fonctionnalités les plus essentielles, ne doivent pas être déployées, ce qui peut accélérer considérablement le développement.

Le principe directeur derrière cela est d'obtenir le logiciel en cours d'exécution aussi rapidement et aussi facilement que possible (faire la chose simple, l'un.

Mais voici un problème. Si vous regardez attentivement, vous constaterez que le principe DRY n'est pas entièrement compatible avec le principe YAGNI. Le premier poursuit "l'abstraction" et nécessite une solution commune, tandis que le second poursuit "fast ness and saving", ce qui signifie ne pas se concentrer sur l'abstraction, car il est probable que "vous n'en aurez pas besoin". Il y a donc un troisième principe.

Règle des trois principes

Règle de trois, connue sous le nom de « principe triple », se réfère à « l'abstraction » lorsqu'une entité apparaît pour la troisième fois.

Cela signifie que la première fois que vous utilisez une fonctionnalité, vous écrivez une solution de contournement spécifique; la deuxième fois que vous l'utilisez, vous copiez le dernier code; et la troisième fois que vous venez, vous commencez à "abstrait" et écrire les solutions qui sont communes.

Il y a plusieurs raisons à cela :

• commode. Si une fonctionnalité n'est utilisée qu'à un ou deux endroits, il ne faut pas de temps pour « s'extraire ».
• Facile à trouver des motifs. L'« abstraction » exige de trouver des modèles de problèmes, et plus il y a de situations dans lesquelles des problèmes surgissent, plus il est facile de voir les modèles, afin qu'ils puissent être « abstraits » avec plus de précision. Par exemple, pour une série de séries, deux éléments ne suffisent pas à déterminer la loi : 1, 2, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,
• Empêche les redondances excessives. Si une fonctionnalité comporte plusieurs implémentations en même temps, elle peut être lourde à gérer et vous devez la modifier à plusieurs endroits. Dans la pratique, une mise en œuvre répétée peut être tolérée tout au plus une fois, et plus ne peut être acceptée.

En résumé, le "triple principe" est le compromis entre le principe DRY et le principe YAGNI, et est l'équilibre entre la redondance du code et le coût de développement, qui vaut la peine d'être suivi lorsque nous "abstraits".