Pourquoi est-il bon de diviser un programme en plusieurs classes?
Je suis encore étudiant au lycée (entrant en 10e année) et je n'ai pas encore suivi de cours d'informatique à l'école. Tout ce que j'ai fait jusqu'à présent se fait à travers des livres. Ces livres m'ont appris des concepts tels que l'héritage, mais comment la division d'un programme en plusieurs classes aide-t-elle? Les livres ne me l'ont jamais dit.
Je pose cette question principalement à cause d'un projet récent. C'est un jeu vidéo d'arcade, un peu comme un jeu Flash comme certains l'ont dit (même si je n'ai aucune idée de ce qu'est un jeu Flash ). Le truc, c'est que ce n'est qu'une classe. Cela fonctionne parfaitement bien (un petit décalage occasionnel cependant) avec une seule classe. Donc, je demande juste comment le diviser en plusieurs classes pourrait l'aider.
Ce projet était en Java et je suis la seule personne à y travailler, pour mémoire.
La réponse la plus simple est que si vous mettez tout dans une seule classe, vous devez vous soucier de tout à la fois lorsque vous écrivez du nouveau code. Cela peut fonctionner pour de petits projets, mais pour des applications énormes (nous parlons de centaines de milliers de lignes), cela devient rapidement presque impossible.
Pour résoudre ce problème, vous divisez des éléments de fonctionnalité en leurs propres classes et encapsulez toute la logique. Ensuite, lorsque vous voulez travailler sur la classe, vous n'avez pas besoin de penser à ce qui se passe d'autre dans le code. Vous pouvez simplement vous concentrer sur ce petit morceau de code. C'est inestimable pour travailler efficacement, mais il est difficile d'apprécier sans travailler sur des applications qui sont énormes.
Bien sûr, il y a d'innombrables autres avantages à diviser votre code en petits morceaux: le code est plus maintenable, plus testable, plus réutilisable, etc., mais pour moi le plus grand avantage est qu'il rend les programmes massifs gérables en réduisant la quantité de code que vous besoin de penser à un moment donné.
Eh bien, la réponse la plus simple pourrait être "Cela aide à organiser les choses". Si rien d'autre, vous pouvez le comparer à des sections d'un cahier - c'est tout simplement plus simple si vous avez "toutes les choses relatives à l'interface utilisateur" ici et "toutes les choses relatives au gameplay" là-bas.
La réponse la plus sophistiquée est que diviser le travail n'est pas seulement pratique, mais très important pour gérer la complexité (et "gérer la complexité" est à peu près le nom du jeu en matière de programmation). Les classes, ou d'autres types de modules, vous permettent de "séparer les préoccupations". Non seulement vous savez où chercher des "éléments liés à l'interface utilisateur", mais vous pouvez être sûr que si vous souhaitez modifier l'interface utilisateur, vous pouvez le faire au même endroit, et vous n'avez pas à le faire vous inquiétez "maintenant, est-ce le niquement endroit où j'ai défini ma police sur Comic Sans?". Et vous pouvez apporter un changement et savoir que l'effet de ce changement ne s'applique qu'à la (petite) portée appropriée. Si tout est dans une seule classe ou un seul module, tout est globalement global, ce qui rend les choses très difficiles à raisonner.
Dans le cas spécifique des classes en tant que type de module logiciel, il y a également beaucoup de comportements associés à une classe, et la plupart des développeurs du paradigme orienté objet trouvent très utile d'avoir des noms significatifs associés aux classes liées au groupe. fonctionne ensemble. Vous n'auriez donc probablement pas de classe UI, vous auriez probablement une classe Button. Il existe tout un ensemble de connaissances et de techniques associées à la conception de classe orientée objet et c'est la façon la plus courante d'organiser de grands systèmes dans la programmation traditionnelle.
C'est une bonne question! Simple et bien demandé. Eh bien ... la réponse n'est pas si facile à comprendre pour un étudiant qui étudie l'informatique et ne sait probablement pas en profondeur OO et n'a probablement pas travaillé sur l'expérience.
Donc, je peux répondre en décrivant un scénario et en vous faisant imaginer à quel point un logiciel multi-classes est meilleur qu'un logiciel monolithique (fabriqué par une seule classe):
- Lisibilité : Il est beaucoup plus difficile de parcourir et d'écrire du code à l'intérieur d'un fichier de 10000 lignes que plusieurs fichiers petits et organisés.
- Réutilisation : Si vous écrivez une seule classe, vous pouvez vous glisser dans duplication de code . Cela signifie plus de lignes de code et probablement plus de bugs (!)
- Testabilité : Qu'en est-il du test d'une seule fonctionnalité? Si vous isolez une fonctionnalité logique dans une classe, votre vie sera plus facile.
- Maintenabilité du code : Vous pouvez corriger un bogue ou améliorer les fonctionnalités avec des classes multipliées en un seul endroit: les jolies petites classes.
- Structure du projet : oooooh pouvez-vous imaginer à quel point un projet laid avec un seul fichier source apparaîtra?
Il y a beaucoup de bonnes réponses ici, et je suis définitivement d'accord avec elles, mais je pense qu'il y a quelque chose de plus intéressant à mentionner.
En ce moment, comme vous l'avez dit, vous travaillez en solo sur votre projet. Cependant, à l'avenir, il y aura des moments où vous devrez travailler en équipe. Pendant ces périodes, vous diviserez le travail (probablement le projet sera assez important). En conséquence, il existe quelques options différentes (je suppose vraiment deux majeures ). Vous pouvez avoir plusieurs copies d'un fichier et travailler sur des "morceaux" séparés du fichier, puis les "combiner" avec un copier-coller plus tard, puis les modifier pour que vos pièces puissent fonctionner ensemble, ou vous pouvez diviser ces "pièces" tout à fait facilement dans différentes classes et discutez comment vous allez écrire ces classes, et utilisez ces connaissances pour commencer.
Il faudra encore travailler pour intégrer toutes les pièces séparées ensemble, mais ce sera beaucoup plus facile à entretenir. Parce que le fichier x contient le code y et c'est le code que vous savez que vous devez modifier. Cela entre dans le domaine de l'organisation dont parlent la plupart des autres réponses.
En fait, ce que vous avez fait, c'est une programmation procédurale réinventée. Attention, il est tout à fait possible d'écrire un logiciel de cette façon et le compilateur ne s'en souciera probablement pas. Pendant de nombreuses années, c'est ainsi que les choses ont été faites jusqu'à ce que les ordinateurs deviennent plus rapides et que les outils s'améliorent.
Cela étant dit, si vous divisez votre code en différentes unités logiques (classes, modules, etc.), vous pouvez avoir beaucoup de petits morceaux de code faciles à comprendre. cela peut être maintenu plus tard. Beaucoup de mes modules ont moins de 20 lignes de code. Je sais que tout le code sur un sujet donné est dans un endroit spécifique. Cela signifie également que si quelqu'un d'autre rejoint le projet, il sera beaucoup plus facile de trouver des choses.
Comme l'a dit Gerald Sussman, nos programmes devraient être écrits en premier pour que les gens puissent les lire et ensuite pour que l'ordinateur puisse les exécuter. (Et si vous n'avez pas encore lu "Structure et interprétation des programmes informatiques, vous devriez")
On utilise plusieurs classes, car à mesure que vous vous lancez dans de plus grandes choses, vous constaterez qu'il est tout simplement impossible de garder une trace de tout quand il s'agit d'un gros tas de code.
Il suffit de diviser pour mieux gérer.
La programmation orientée objet est la meilleure idée que j'ai jamais vue en programmation. Mais ce n'est pas la meilleure chose dans tous les cas, vous avez besoin d'un peu d'expérience en programmation pour en comprendre l'intérêt, et beaucoup de gens prétendent faire OOP quand ils ne le sont pas) .
Si vous pouvez rechercher une "programmation structurée", vous trouverez probablement quelque chose de plus immédiatement utile. (Assurez-vous de lire ancienne programmation structurée. Les anciens termes ont souvent de nouvelles significations plus sophistiquées, et vous n'avez pas encore besoin de fantaisie.) Ceci est un concept assez simple pour décomposer votre programme en sous-programmes. , ce qui est beaucoup plus facile que de le décomposer en objets. L'idée est que votre programme principal est une courte routine qui appelle des sous-programmes ("méthodes" en Java) pour faire le travail. Chaque sous-programme ne sait que ce que ses paramètres lui disent. (L'un de ces paramètres peut être un nom de fichier, vous pouvez donc tricher un peu.) Donc, regarder l'en-tête d'un sous-programme/méthode vous donne une idée rapide de ce qu'il fait et savoir ce que les méthodes du programme principal permettent vous voyez ce que it fait presque en un coup d'œil.
Ensuite, tous les sous-programmes sont décomposés de la même manière jusqu'à ce que quelques lignes de code sans appel de méthode fassent le travail. Un programme principal qui appelle quelques méthodes, chacune appelant quelques méthodes, chacune d'elles .... Jusqu'aux petites méthodes simples qui font le travail. De cette façon, vous pouvez regarder n'importe quelle partie d'un très grand programme (ou petit programme) et comprendre rapidement ce qu'il fait.
Java est spécialement conçu pour les personnes qui écrivent du code orienté objet. Mais même le programme OO le plus intense utilise une programmation structurée, et vous pouvez toujours renverser n'importe quel langage. (J'ai fait OO en clair C.)). faire SP, ou toute autre chose, en Java. Oubliez les classes et concentrez-vous sur les grandes méthodes qui peuvent être décomposées en petites, gérables. Je dois ajouter que SP aide beaucoup à vous permettre de réutiliser votre et aussi avec le principe DRY (google it, mais cela signifie "Don't Repeat Yourself")).
J'espère avoir expliqué pourquoi et comment diviser votre code en plusieurs parties sans apporter de "classes". Ils sont une excellente idée et sont juste la chose pour les jeux et Java est un excellent langage pour OOP. Mais il vaut mieux savoir pourquoi vous faites ce que vous faites. Laissez OOP seul) jusqu'à ce qu'il commence à vous donner un sens.
L'un des avantages est la réutilisation. Un programme est essentiellement un tas d'instructions regroupées. Vous constaterez que certaines de ces instructions conviennent également à d'autres programmes.
Disons que vous faites un jeu de saut. Plus tard, lorsque vous décidez de faire un jeu de canon, vous trouvez que le calcul physique que vous avez utilisé dans le jeu de saut est utile ici.
Donc, au lieu de l'écrire à nouveau, ou pire de le copier et de le coller dans le nouveau programme, vous en faites une classe. Donc, la prochaine fois que vous créez un autre jeu où la mécanique du jeu nécessite de la physique, vous pouvez simplement le réutiliser. Bien sûr, c'est trop simplifié, mais j'espère que cela a du sens.
Il ne s'agit pas de diviser un programme en classes, mais de savoir comment vous modélisez votre application, c'est-à-dire comment vous visualisez des parties de votre application. Le fractionnement des choses n'est qu'un mécanisme que nous utilisons pour mieux comprendre les choses complexes. Ce n'est pas seulement avec la programmation. Imaginez une carte de circuit imprimé avec de nombreux fils entrelacés, formant une structure complexe avec chaque fil se connectant quelque part (code spaghetti). Vous devrez suivre chaque fil jusqu'à sa fin pour comprendre les connexions. Imaginez au contraire des fils qui sont groupés et codés par couleur selon leur fonction. Il devient beaucoup plus facile de réparer les choses.
L'idée est que vous ne commencez pas avec un programme long et que vous le divisez ensuite en classes. Mais vous modélisez d'abord votre application en termes d'objets/classes, puis vous les connectez pour créer des applications.
Tout d'abord, notez que je suis un C++ et Python, pas Java, donc certains de ces éléments peuvent ne pas s'appliquer aussi complètement. Veuillez me corriger si je fais des hypothèses incorrectes sur le fonctionnement des classes en Java.
Les classes sont principalement utiles lorsqu'elles sont instanciées. Une classe dont aucune instance n'est créée n'est vraiment qu'un espace de noms glorifié. Si vous utilisez toutes vos classes de cette manière, alors en effet, les avantages de déplacer des choses d'un espace de noms vers un espace de noms peuvent sembler insignifiants - tout au plus, vous gagnerez en ayant des données privées dans chacune et ainsi encapsulez un peu les choses.
Cependant, ce n'est pas là que les classes brillent. Considérez la classe String: vous pourriez avoir toutes les mêmes fonctionnalités en utilisant les tableaux char et certaines fonctions statiques. À ce stade, les fonctions vous donnent un peu plus de sécurité et de sucre syntaxique. Vous pouvez écrire string.length() au lieu de length(char_array); ce n'est pas un gros problème, mais beaucoup de gens l'aiment encore. De plus, vous savez que si quelqu'un vous a donné un String, il a été créé avec le constructeur String et qu'il doit fonctionner avec la fonction length - si la version du tableau peut 't gérer un certain caractère alors il n'a aucun moyen de vous empêcher de le mettre là-dedans.
Mais ce n'est toujours pas ça. Le point clé est que les classes regroupent les données et les fonctions qui les exploitent et les enlèvent toutes les deux. Lorsque vous avez une méthode void f(Builder b) vous savez que vous obtiendrez un Builder, et vous pouvez vous attendre à ce qu'elle prenne en charge certains comportements. Cependant, vous ne savez rien des données ou des fonctions en cours d'exécution - en fait, les définitions des deux peuvent ne pas encore être écrites lorsque vous écrivez et compilez f.
Le premier point à comprendre est donc que les classes facilitent la transmission des données tout en s'assurant qu'elles ne sont pas cassées. Le deuxième point est que les données et les fonctions (implémentations) d'un objet sont quelque chose à propos de l'objet, pas quelque chose que vous pouvez simplement dire de son type.
L'idée est basée sur une règle générale nommée diviser pour mieux régner .
Ce paradigme peut être utilisé presque partout; vous divisez un problème en problèmes plus petits, puis vous résolvez ces petits problèmes simples et bien connus.
La division de votre programme en classes est l'un des types de divisions qui ont commencé à devenir courants au cours de la dernière décennie. Dans ce paradigme de programmation, nous modélisons notre problème par certains objets et essayons de résoudre le problème en envoyant des messages entre ces objets.
Certaines personnes pourraient dire que cette approche est plus facile à comprendre, à développer et à déboguer.
Bien que certaines personnes en désaccord :)