Il se trouve que le projet est au point mort et que son développement ultérieur devient impossible. Il n'est pas rare que la raison d'un tel échec soit l'architecture infructueuse définie au début du développement. Ou devez-vous discuter de laquelle des "deux chaises" est la meilleure, ou peut-être même participer et ne pas comprendre sincèrement comment votre adversaire peut le penser!?
Ensuite, nous essaierons de ne pas comprendre beaucoup d'abstractions, d'où elles viennent et que faire avec elles.
Selon Wikipedia, l' abstraction est une généralisation théorique résultant de l'abstraction. À son tour, l'abstraction est une distraction dans le processus de cognition des parties non essentielles, des propriétés, des relations d'un objet (objet ou phénomène) afin de mettre en évidence leurs caractéristiques essentielles et régulières.
De la définition, nous pouvons conclure que seule une signification peut être une abstraction. Dans ce cas, la perception n'est qu'une projection du monde réel. Il s'avère que toutes les réflexions sur le réel sont des réflexions sur nos modèles du réel.
Les abstractions forment des hiérarchies et peuvent être identifiées avec des entités privées et combiner des entités similaires en des abstractions de niveau supérieur.
Abstractions de conscience
En plus du prisme de la perception, nos modèles sont soumis à une autre distorsion: les entités réelles sont extrêmement complexes et ont différents aspects et paramètres. Lorsque l'on pense ou parle de quelque chose, il y a toujours un contexte dans lequel un modèle existe. Et parfois, il arrive que les interlocuteurs de ce contexte soient différents. Et pour couronner le tout, la présence ou l'absence d'expérience (globale) conduit à un changement encore plus important de nos modèles en fonction de cette expérience. En conséquence, deux personnes différentes peuvent avoir des perceptions très différentes des mêmes entités du monde réel.
Il s'avère que chaque personne est constamment confrontée à des abstractions, il reste à apprendre à les voir et à les gérer clairement. On peut avancer la thèse que le code programme est une simulation de la pensée basée sur des abstractions formalisées. Par conséquent, à mon avis, le développement de logiciels est l'un des meilleurs simulateurs pour pomper la pensée abstraite.
Abstraction en développement
Les interfaces de programmation sont peut-être l'abstraction formalisée la plus évidente. Tout ce qui est superflu est coupé et seul «ce qu'il fait» reste sans «comment il fait».
En mettant en œuvre l'interface, nous créons un modèle de comportement ou d'interaction plus réaliste, qui peut déjà répondre à la question «comment». En combinant les interfaces entre elles, nous pouvons créer une architecture de code commune. Avec une habileté et une dextérité appropriées, l'architecture ainsi créée conservera sa structure à l'avenir. Alors que la mise en œuvre des interfaces composites peut changer au-delà de la reconnaissance.
Cette architecture simplifie certains points du travail. Les tests unitaires se résument à l'écriture d'implémentations de test d'abstractions "voisines" et de méthodes de test comparant les entrées et les sorties. L'isolation des modules vous permet d'effectuer en toute sécurité un refactoring. De plus, si le refactoring a échoué et que tout s'est cassé, vous ne devrez annuler qu'un seul module. Un module suffisamment abstrait peut être utilisé pour des tâches similaires mais différentes. Dans le même temps, une mauvaise mise en œuvre n'affectera pas le travail des autres - l'isolement de govnokod.
ExempleIl existe un module de traitement des données d'entrée, il existe plusieurs options pour les obtenir: à partir de la base de données; du fichier; par http. Ce problème peut être résolu en mettant en évidence une interface commune pour recevoir des données et en réalisant une implémentation pour chaque canal et canal de données à tester. Maintenant, un gestionnaire peut résoudre plusieurs problèmes similaires en utilisant le paramètre «canal de données». Et s'il s'avère que l'une des implémentations est une courbe, elle peut être refaite pour affecter d'autres modules.
Les abstractions ne sont plus nécessaires
Il n'y a pas de solutions parfaites, et donc avec les abstractions, les choses ne sont pas si fluides. Tout d'abord, les abstractions sont subjectives, elles peuvent provoquer un débat sur le point de départ de l'un et de l'autre. Il y a aussi le problème de l'abstraction excessive, quand une abstraction différente est créée pour chaque type et tonalité d'un éternuement. Deuxièmement, cette approche augmente la complexité du code en ajoutant de nouvelles entités et de nouveaux niveaux de hiérarchie. Je suis sûr qu’il y aura encore des lacunes dans cette approche, certaines d’entre elles seront subjectives, partiellement situationnelles, mais
Il devrait y avoir un équilibre en tout. Pour moi, j'ai déduit la note suivante.
- Si vous écrivez un module important et important, il est préférable de le désengager.
- Si le module est beaucoup utilisé et / ou à différents endroits, il est préférable de le cacher derrière une abstraction.
- Si le module doit être distribué en tant que bibliothèque distincte, il est préférable d'utiliser des abstractions.
- S'il est possible de changer des algorithmes ou des chemins d'interaction, il est préférable de mettre en œuvre l'interaction des abstractions.
- Si la classe est utilisée dans une autre classe et nulle part ailleurs - vous pouvez penser à les combiner ou à la laisser telle quelle.
- S'il s'agit d'une petite tâche "ponctuelle" - il vaut mieux ne pas s'embêter avec sa complication.
- S'il s'agit d'un module qui ne changera probablement jamais - vous pouvez afficher son interface et il est préférable de tout laisser tel quel.
Total
Les abstractions sont un outil intégré à notre conscience, comme tout autre, elles ont leurs avantages et leurs inconvénients, mais connaître les alternatives n'aide qu'à trouver un meilleur moyen.