Pourquoi est-il considéré comme une meilleure pratique de regrouper le code du programme et le code de l'interface graphique dans différentes classes?

15

Mon professeur me dit donc qu'il est très important de ne pas encapsuler le code du programme et le code de l'interface graphique dans les mêmes classes, mais de les garder complètement indépendants. Im écrit actuellement un jeu iphone avec une grille en elle. pour moi, il est beaucoup plus logique de créer à la fois la grille graphique et le code technique dans la même classe "Grille". Est-ce qu'un autre programmeur froncer les sourcils à ce sujet? Est-il en effet très important de garder l'interface graphique et le code indépendants. Quels problèmes se poseront si je ne le fais pas?

Je vous remercie!

EDIT: merci les gars! Serait-il correct pour moi de rédiger le projet en premier, puis de copier le code pour former la séparation des préoccupations. Je sais que cela peut totalement nuire à l'objectif, mais tout comme la pratique ... Pour que la prochaine fois, je puisse appliquer ce modèle de conception dès le début?

John
la source

Réponses:

17

Le concept auquel votre enseignant fait référence est quelque chose appelé séparation des préoccupations.

Pour l'illustrer dans votre contexte, si vous terminez votre programme et décidez ensuite de le porter sur Android; vous devrez réécrire beaucoup plus de code que si vous aviez séparé la logique de la grille.

Un contrôle d'interface ne doit se préoccuper que de dessiner ce qui lui est dit, la logique de la grille ne doit se préoccuper que de ce qu'il y a dans la grille, pas comment le dessiner.

Est-ce que cela aide ?

Russ Clarke
la source
Merci, cela a aidé. Le fait est que c'est beaucoup plus facile pour moi de visualiser mon produit final lorsque j'encapsule les deux dans une classe. Est-ce une raison valable pour moi de ne pas suivre la "séparation des préoccupations"? Ou est-ce absolument nécessaire et je ne pourrais pas m'appeler un bon programmeur: p?
Un effet positif de cette séparation est que vous n'avez pas à réécrire votre logique de jeu, si vous choisissez de remplacer votre interface graphique par exemple
@John - Rédigez un document de spécification si vous avez besoin de visualiser votre conception. Si vous pouvez le décrire, vous pouvez commencer à séparer le code d'interface graphique de la logique du jeu lui-même.
Ramhound
3
Cela rend également le code de grille plus facile à tester. Tester les interfaces graphiques est douloureux (en raison de possibles problèmes de confusion des environnements), donc obtenir que l'interface graphique soit une fine couche «évidemment correcte» sur quelque chose qui est testable est une énorme victoire. (Encore une fois, il s'agit de la séparation des préoccupations.)
Donal Fellows
1
@John: Certains d'entre nous apprennent mieux en faisant. En supposant que ce projet n'est pas si grand, essayez de l'écrire en une seule classe et de le faire fonctionner sur l'iPhone. Maintenant, portez-le sur Android, gardez une trace de vos «points douloureux». Enfin, réécrivez-le comme Russ C l'a suggéré. Je pense que vous verrez pourquoi la séparation de la logique et de la présentation est la voie à suivre.
Peter Rowell
4

Pour faciliter la modification de votre code . Et si demain vous ne voulez pas utiliser une grille mais une liste? Lorsque votre interface graphique est séparée de votre logique, c'est facile à faire.

En plus de cela, vous écrirez du code plus réutilisable . Si votre interface graphique ne contient pas votre code technique, vous pouvez également le réutiliser. Créez une grille fantaisie avec toutes les options une fois et vous pouvez l'utiliser dans d'autres projets. Mélanger votre interface graphique et votre code technique vous empêchera de le faire.

Il vous donne également un code plus facile à lire. Si votre grille ne fait que la fonctionnalité GUI, il est plus facile de comprendre ou de modifier votre code.

Carra
la source
3

L'approche générale de la programmation orientée objet à une séparation des préoccupations , où le code est séparé en tâches logiques. Au début, cela peut sembler plus de travail. Mais à mesure que votre projet se développe, cela facilite le suivi et la gestion de votre code.

Pour cette raison, il serait probablement préférable de séparer le code responsable de l'affichage d'une grille et le code qui traite des données qui peuvent être affichées dans cette grille.

Jonathan Wood
la source
1

Lorsque la séparation des préoccupations est appliquée à une structure d'application, le résultat est une architecture à plusieurs niveaux (ou architecture à N niveaux ) http://en.wikipedia.org/wiki/Multitier_architecture .

StuperUser
la source
0

Pour s'appuyer sur les autres réponses et vous donner un exemple, vous devez vous permettre en quelque sorte d'injecter votre logique / vos données dans votre grille ou vice versa.

Votre contrôle de grille peut exposer une Renderméthode ou une DataBindméthode.

class GridControl
{
    public Render(GridData data) { ... }
}

ou

class GridControl
{
    public DataBind(GridData data) { ... }
}

Ensuite, votre unité logique peut soit prendre le GridControl et lui lier un objet de données, soit appeler manuellement le rendu avec l'objet de données chaque fois que quelque chose change.

Votre GridLogic devrait également avoir une référence au GridControl afin qu'il puisse se lier à toute entrée / événement se produisant.

L'idée derrière la liaison de données est que votre contrôle de grille surveille les données pour tout changement et se restitue alors qu'exposer une fonction de rendu signifie que votre unité logique restitue manuellement le contrôle.

Dans les deux cas, diviser votre logique et votre grille comme ceci vous permet de changer plus facilement l'un de l'autre sans rien casser. Vous pouvez également écrire un nouveau contrôle comme un ListControlpour afficher vos données sous forme de liste au lieu d'une grille sans avoir à réécrire toute votre logique.

Raynos
la source
0

Je vous recommande fortement de jeter un œil à l' architecture MVC .

C'est un raffinement du concept que vous avez mentionné (séparation du code du programme et de l'interface graphique). MVC signifie Model-View-Controller. Ici, le modèle est les données, la vue est le code de l'interface graphique et COntroller est le code qui traite les données.

De cette façon, vous avez créé trois parties de votre programme. Chaque pièce peut être remplacée sans nécessiter de modification des deux autres pièces.

DPD
la source
0

Cela dépend des types de changements futurs auxquels vous pouvez vous attendre. Ce que vous voulez minimiser, c'est le nombre de changements de code manuels nécessaires pour implémenter correctement chaque changement fonctionnel unique.

Où MVC gagne, c'est si les changements sont limités à la partie V, ou "View".

D'après mon expérience, il est beaucoup plus probable que les changements affectent les trois parties, il est donc préférable qu'ils ne soient pas séparés. Pour montrer ce que je veux dire, j'ai longtemps utilisé une technique que j'ai développée appelée Dynamic Dialogs , dans laquelle une nouvelle exigence, telle que "permettre à l'utilisateur de modifier le nom, et une fois terminé faire XYZ" est entrée dans le code source comme un seul bloc de texte:

if(deTextEdit(&sName)){
  // do XYZ
}

au lieu de plusieurs modifications distinctes, pour spécifier que le champ d'édition existe, pour en créer un identifiant unique, pour le lier à la variable de modèle et pour le lier au gestionnaire d'événements à focus perdu.

Si vous accédez à ce lien, vous verrez un exemple plus complexe.

Fondamentalement, l'idée est de transformer le code en un langage spécifique au domaine, afin de minimiser le nombre de modifications pour atteindre l'objectif. La raison pour laquelle vous voulez le faire est non seulement de réduire l'effort, mais aussi de réduire la possibilité d'introduire des bogues, en oubliant ou en codant mal une ou plusieurs des modifications. Il réduit également la taille du code source d'environ un ordre de grandeur.

Ce n'est pas gratuit. Il introduit une courbe d'apprentissage unique pour le programmeur.

Mike Dunlavey
la source
0

L'interface graphique dépend du système, tandis que le noyau du jeu est un algorithme totalement indépendant du système sur lequel il fonctionne. Garder les deux appart facilitera la maintenance, le test et le débogage du programme car les changements dans un sous-système n'affectent pas le fonctionnement de l'autre. Même si vous ne vous souciez pas de la portabilité, je parie que vous vous souciez de la robustesse et de la maintenabilité de votre programme.

Gus
la source