5

J'ai un autre programmeur que j'essaye d'expliquer pourquoi c'est qu'un composant d'IU ne devrait pas être aussi une structure de données.Comment expliquer à quelqu'un qu'une structure de données ne devrait pas se dessiner, expliquant la séparation des préoccupations?

Par exemple dire que vous obtenez une structure de données qui contient un enregistrement retrouve à partir des « base de données », et que vous souhaitez afficher cet enregistrement, situé dans un composant d'interface utilisateur dans votre application.

Selon ce programmeur (qui restera anonyme, il est jeune et je lui enseigne ...), nous devrions sous-classer la structure de données dans une classe qui va dessiner le composant de l'interface utilisateur dans notre application !!!! !!

Et donc selon cette logique, l'enregistrement doit gérer ensemble le dessin de l'interface utilisateur.

****** Head bureau *****

Je sais que demander un enregistrement mis à se dessiner est faux, parce que, si vous souhaitez rendre la même structure de données sur plus de un type de composant sur votre interface utilisateur, vous allez avoir un vrai bordel sur vos mains; vous devrez étendre une autre classe pour chaque composant de l'interface utilisateur que vous affichez à partir de la classe de base de votre jeu d'enregistrements; Je connais bien la "propreté" du pattern MVC (et par là ce que je veux vraiment dire, c'est que vous ne confondez pas vos données (le Model) avec votre UI (la vue) ou les actions qui avoir lieu sur les données (le contrôleur plus ou moins ... okay pas vraiment l'API devrait vraiment gérer ça ... et le contrôleur devrait juste faire aussi peu d'appels que possible, en lui disant quelle vue afficher) C'est certainement beaucoup plus propre que d'utiliser des structures de données pour rendre les composants de l'interface utilisateur!

Y at-il autre conseil que je pourrais envoyer son chemin autre que l'exemple ci-dessus? Je comprends que lorsque vous apprenez pour la première fois, vous passez par «une étape» où vous voulez juste tout étendre. Suivi par une étape quand vous pensez que les motifs de conception sont la solution à chaque problème ... ce qui n'est pas tout à fait correct non plus ... thanks Jeff.

Est-il possible que je peux pousser doucement ce gamin dans la bonne direction? Avez-vous d'autres exemples qui pourraient aider à expliquer mon point à lui?

Répondre

4

Avez-vous entendu parler de Martin Fowler?

Separating User Interface Code

Quoi qu'il en soit, s'il veut aller plus loin dans cette direction d'ajouter à ses méthodes rendent les contrôles de données, ont l'air lui à « couplage lâche ». Il est possible de créer un type d'interface générique qui l'amène à mi-chemin, mais le composant de l'interface utilisateur devrait le faire tout le reste.

0

Cela se résume à fonctionnelle par rapport à responsabilités non fonctionnelles. Ce que la structure de données fait et comment elle est visualisée sont deux choses complètement séparées - essentiellement la racine du modèle MVC.

Il y a aussi une notion de dépendances circulaires ici. Puisque l'interface utilisateur doit connaître les structures de données, si vous autorisez les structures de données à dépendre de l'interface utilisateur, vous obtenez une bonne petite boule de boue.

+0

Et par fonctionnel, vous voulez dire interagir avec les données avec l'interface utilisateur, et être non fonctionnel; juste un conteneur pour les données, comme le résultat-ensemble ... non? – leeand00

+0

Fonctionnel comme dans "what something does", non-fonctionnel comme dans "comment quelque chose a l'air". Dans MVC, le «ce que quelque chose fait» est le modèle, et «comment quelque chose ressemble» est la visualisation du modèle, la vue. –

0

En général, sur le point de découplage:

  1. Non seulement peut-il y avoir différentes composantes de l'interface utilisateur rendant la même structure de données. Vous pouvez même avoir des interfaces utilisateur complètement différentes (Web, Application de bureau, ...) Maintenant, bien sûr, vous pouvez sous-classer Person avec WebPerson et DesktopPerson(cela semble déjà faux, n'est-ce pas? Personne - il s'agit de quelque chose d'autre). Chaque interface utilisateur pourrait fonctionner sur différents types de personnes, par ex. Teacher et Student. On obtient ainsi WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher et DesktopStudent.

Maintenant, disons, WebPerson définit la méthode "drawAddressFields()" pour dessiner une version web des champs d'adresse. Mais puisque WebTeacher doit dériver de Teacher pour utiliser le champ de données supplémentaire "salary" (et supposons un héritage unique), il doit implémenter "drawAddressFields()" encore une fois!

Alors peut-être l'argument de « cela entraînera beaucoup plus de travail » contribuera à créer une certaine motivation :-)

BTW, cela conduira automatiquement à la création d'un certain délégué qui met en œuvre le code de drawAddressField(), qui évoluera ensuite vers la création d'un composant qui exécute le dessin séparément de la structure de données.

Questions connexes