C'est une question assez vague, mais c'est quelque chose que je n'ai jamais senti avoir reçu de réponse satisfaisante lors de la lecture sur la conception appropriée.
Généralement, lorsque vous apprenez la programmation orientée objet, l'abstraction, l'affacturage, etc., le Saint Graal de la conception - et la raison pour laquelle ils prétendent toujours que vous utilisez les techniques de développement en question - est que cela rendra votre programme "facile à changer" , "maintenable", "flexible" ou l'un des synonymes utilisés pour exprimer un tel concept à consonance productive. En marquant ivars comme privé, en divisant le code en de nombreuses petites méthodes autonomes, en gardant les interfaces générales, vous êtes censé avoir la possibilité de modifier votre programme en toute simplicité et grâce.
Pour des changements relativement petits, cela a bien fonctionné pour moi. Les modifications apportées aux structures de données internes utilisées par une classe pour augmenter les performances n'ont jamais été une difficulté majeure, pas plus que les modifications apportées à l'interface utilisateur, indépendamment de l'API, telles que la refonte d'un système de saisie de texte ou la refonte des graphiques d'un élément de gameplay. .
Tous ces changements semblent intrinsèquement autonomes. Aucun d'entre eux n'implique de modification du comportement ou de la conception du composant de votre programme en cours de modification, en ce qui concerne le code extérieur concerné. Que vous écriviez ou non de manière procédurale ou dans un style OO, avec des fonctions grandes ou petites, ce sont des changements faciles à faire même si vous n'avez qu'un design modérément bon.
Cependant, chaque fois que les changements deviennent importants et velus - c'est-à-dire les changements de l'API - aucun de mes précieux «modèles» ne vient à la rescousse. Le grand changement reste important, le code affecté reste affecté et de nombreuses heures de travail de génération de bogues m'attendent.
Voici donc ma question. Quelle est l'ampleur d'un changement que la conception appropriée prétend pouvoir faciliter? Y a-t-il une autre technique de conception, inconnue de moi ou que je n'ai pas mise en œuvre, qui rend vraiment simple la modification au son collant, ou est-ce que la promesse (que j'ai entendu faire par tant de paradigmes différents) n'est qu'une idée sympa, complètement déconnecté des vérités immuables du développement logiciel? Existe-t-il un «outil de changement» que je peux ajouter à ma ceinture d'outils?
Plus précisément, le problème auquel je suis confronté qui m'a conduit aux forums est le suivant: j'ai travaillé sur la mise en œuvre d'un langage de programmation interprété (implémenté en D, mais ce n'est pas pertinent), et j'ai décidé que les arguments de mes fermetures devraient être basé sur des mots clés, plutôt que positionnel comme ils le sont actuellement. Cela nécessite de modifier tout le code existant qui appelle des fonctions anonymes, ce qui, heureusement, est assez petit car je suis au début du développement de mon langage (<2000 lignes), mais ce serait énorme si j'avais pris cette décision à un stade ultérieur. Dans une telle situation, y a-t-il un moyen qui, grâce à une bonne prévoyance dans la conception, aurait pu faciliter cette modification, ou certains (la plupart) des changements sont-ils intrinsèquement de grande portée? Je suis curieux de savoir si cela est en quelque sorte un échec de mes propres compétences en conception - si c'est le cas, je '
Pour être clair, je ne suis en aucun cas sceptique vis-à-vis de la POO ou de tout autre modèle couramment utilisé. Pour moi, cependant, leurs vertus sont dans l'écriture originale, plutôt que dans le maintien, des bases de code. L'héritage vous permet de bien résumer les motifs répétitifs, le polymorphisme vous permet de séparer le code par fonction comprise par l'homme (quelle classe) plutôt que par effet compris par la machine (quelle branche de l' switch
instruction), et de petites fonctions autonomes vous permettent de écrire dans un style "bottom-up" très agréable. Cependant, je suis sceptique quant à leurs prétentions de flexibilité.
foo metarg1: bar metarg2: baz
comme foo.metarg1_metarg2_(bar, baz)
. Cependant, ma langue fait un changement plus important, à savoir les paramètres basés sur la liste en paramètres basés sur le dictionnaire, ce qui affecte le runtime mais pas l'analyseur, en fait, en raison des propriétés spécifiques de ma langue, je n'entrerai pas en ce moment. Comme il n'y a pas de mappage clair entre les mots-clés non ordonnés et les arguments positionnels, le runtime est le principal problème.