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?

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?

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 ?

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.

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.

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 .

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.

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.

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.

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.