Comment structurez-vous un programme java?

Un principe fondamental du bon développement logiciel est le principe de responsabilité unique . Il indique qu'une fonction ou une classe ne doit avoir une responsabilité.

De cette façon, vos classes et objets ne devraient pas devenir trop gros et ingérables.

Je pense que l'un des concepts les plus importants à maîtriser lors du développement de logiciels est le concept ou Orthogonalité. Ce n'est pas la définition la plus simple, mais cela signifie essentiellement qu'un composant (comme la lecture des clics de souris) ne doit pas être directement lié à un composant non lié (déplacer un carré à l'écran).

Dans votre cas, les clics de souris de lecture de code doivent être séparés du code qui déplace réellement la boîte. Que vous l'implémentiez en tant que classes internes / anonymes ou non, c'est à vous. Mais si vous suivez le principe d'Orthogonalité, il sera facile de changer à une date ultérieure si vous changez d'avis.

Un problème ici est que toutes les règles ont une certaine marge de manœuvre où vous devez utiliser votre propre jugement.

Par exemple, l'application que vous décrivez maintenant me semble si simple que je le ferais probablement dans une seule classe, avec peut-être quelques classes imbriquées, peut-être anonymes. En tout état de cause, je pourrais faire un cas décent pour adapter le tout dans un seul fichier source, affirmant que plusieurs fichiers source augmenteraient en fait la complexité de l'ensemble chose.

Mais si votre interface graphique avait un certain nombre de contrôles différents, chacun contrôlant peut-être un comportement différent, il deviendrait temps de diviser la fonctionnalité afin que vous ne vous retrouviez pas avec un gros bol de code spaghetti.

Les bibliothèques Java GUI essaient de séparer naturellement (view+controller) du model. Vous êtes encouragé à définir et à afficher l'interface graphique dans un module (= fichier) mais à avoir votre modèle de données et peut-être votre fonctionnalité dans un autre. Pour les interfaces graphiques compliquées, il peut également y avoir plusieurs modules d'implémentation GUI maintenus ensemble par code.

Une façon de garder les choses "propres" est de travailler dans des "calques" où chaque calque "ne sait" que ce qu'il doit savoir. Pour être spécifique, la couche GUI doit connaître l'existence de ses modèles sous – jacents-tables et listes et autres choses n'ont pas besoin d'être connectées à TableModels et ListModels, etc. Il n'a cependant pas besoin de connaître les détails de ces modèles, il peut donc simplement se référer à ces modèles par interface.

La couche modèle, sur le d'autre part, besoin de ne rien savoir sur l'interface graphique. Moins il en sait, mieux c'est, et cela vous permettrait théoriquement d'échanger des interfaces graphiques sans avoir besoin de toucher les modèles.

Mon modèle peut également contenir ActionListener s pour répondre aux actions entreprises par exemple en appuyant sur des boutons dans l'interface graphique.

Bien sûr, les actions et les modifications apportées au modèle entraînent souvent des modifications de l'interface graphique. Comment communiquer ces modifications à l'interface graphique si la couche modèle ne connaît pas l'interface graphique? Vous pouvez utiliser un haricot lié propriétés ici. Voici un court tutoriel: http://www.javalobby.org/java/forums/t19476.html . Vous avez donc le même type de structure: les changements se produisent dans votre modèle, ils sont communiqués aux beans avec le support de changement de propriété dans le modèle, et l'interface graphique peut attacher des écouteurs à ces propriétés pour découvrir quelque chose de changé.

Si vous effectuez des actions réelles et efficaces (par exemple, écrire des fichiers, convertir des données, etc.) dans votre code de modèle ou si vous divisez le " traitement" le code dans un autre module dépend de vous et dépendra à nouveau de l'encombrement de votre modèle. S'il y a une petite poignée de champs et de méthodes qui se sentent seuls, vous pouvez décider d'écraser les choses ensemble, mais au moment où cela commence à paraître désordonné, vous voudrez refactoriser votre code de traitement dans son propre module. Le traitement ressemble au type de module qui ne veut pas non plus connaître les autres modules; vous pouvez simplement appeler ses méthodes à partir du modèle niveau.

J'ai décrit mon style de base pour faire le développement de l'interface graphique. Il existe certainement d'autres recommandations, et vous développerez probablement votre propre style en fonction de votre expérience. C'est juste destiné à vous donner une idée et un point de départ possible.

... l'utilisateur clique et le carré se déplace à l'endroit où l'utilisateur a cliqué arrondi, au carré de grille le plus proche.

Voici un exemple de faire cela dans une vue à l'échelle.

Étape 1 - trouvez les applets de démonstration fournis par Sun. http://java.sun.com/applets/jdk/

Étape 2 - lisez ces applets de démonstration. Au moins trois. De préférence, chacun d'entre eux.

Si vous avez lu plusieurs applets, vous devriez voir un peu plus clairement comment organiser les programmes. Vous pouvez ensuite poser des questions avec beaucoup plus de concentration pointant vers des exemples d'applet spécifiques et votre problème de programmation spécifique.

Ouais, je suis moi-même un programmeur débutant. Oui, la séparation des fonctionnalités entre plusieurs classes est un bon moyen de réduire la complexité et d'augmenter la cohésion des classes individuelles.

Augmenter la cohésion est bon car en ayant une structure de données plus complexe, vos algorithmes deviennent moins complexes et votre code est moins dépendant les uns des autres.

Par exemple, dans votre cas, il pourrait être judicieux de séparer les classes conformément à MVC (Model View Controler ).

• Vous avez un modèle qui représente la façon dont vos données de jeu sont structurées.
• Vous avez une visionneuse qui présente votre Modèle sous la forme que vous voulez.
• Avoir un contrôleur qui capte les changements dans le modèle (via les écouteurs) puis met à jour la visionneuse

Vous pouvez maintenant modifier votre modèle et ajouter des fonctionnalités supplémentaires ne nécessitant que de petites modifications dans le fonctionnement de la visionneuse.

Il y a beaucoup de Modèles, mais il y n'est pas une règle difficile quand utiliser l'un sur l'autre. Il y a certains cas dans lesquels vous pouvez en utiliser plusieurs et il y a des cas dans lesquels vous devrez choisir un modèle de conception plutôt que l'autre.

Chaque programmeur Java débutant doit commencer par les tutoriels Sun. Ils sont très bons.

Une autre bonne source, en particulier parmi les sources libres, est "Thinking in Java" de Bruce Eckel, disponible à partir de http://www.mindview.net/Books/TIJ/.

Mais ce dernier est un peu daté par rapport au premier. C'est pourquoi je recommande à la fois.