Dans le passé, j'ai utilisé l'héritage pour permettre l'extension des formulaires Windows dans mon application. Si tous mes formulaires avaient des contrôles, des illustrations et des fonctionnalités communs, je créerais un formulaire de base implémentant les contrôles et les fonctionnalités communs, puis autoriserais d'autres contrôles à hériter de ce formulaire de base. Cependant, j'ai rencontré quelques problèmes avec cette conception.
Les contrôles ne peuvent être que dans un seul conteneur à la fois, donc tous les contrôles statiques dont vous disposez seront délicats. Par exemple: Supposons que vous disposiez d'un formulaire de base appelé BaseForm qui contenait un TreeView que vous rendez protégé et statique afin que toutes les autres instances (dérivées) de cette classe puissent modifier et afficher le même TreeView. Cela ne fonctionnerait pas pour plusieurs classes héritant de BaseForm, car TreeView ne peut être que dans un seul conteneur à la fois. Ce serait probablement sur le dernier formulaire initialisé. Bien que chaque instance puisse modifier le contrôle, il ne s'afficherait que dans un à un moment donné. Bien sûr, il existe des solutions de contournement, mais elles sont toutes laides. (Cela me semble être une très mauvaise conception. Pourquoi plusieurs conteneurs ne peuvent-ils pas stocker des pointeurs vers le même objet? Quoi qu'il en soit, c'est ce que c'est.)
Indiquez entre les formulaires, c'est-à-dire les états des boutons, le texte des étiquettes, etc., je dois utiliser des variables globales et réinitialiser les états lors du chargement.
Ce n'est pas vraiment très bien pris en charge par le concepteur de Visual Studio.
Existe-t-il une conception meilleure, mais toujours facile à entretenir? Ou l'héritage de forme est-il toujours la meilleure approche?
Mise à jour Je suis passé de MVC à MVP au modèle d'observateur au modèle d'événement. Voici ce que je pense pour le moment, veuillez critiquer:
Ma classe BaseForm contiendra uniquement les contrôles et les événements connectés à ces contrôles. Tous les événements qui nécessitent une sorte de logique pour les gérer passeront immédiatement à la classe BaseFormPresenter. Cette classe gérera les données de l'interface utilisateur, effectuera toutes les opérations logiques, puis mettra à jour le BaseFormModel. Le modèle exposera les événements, qui se déclencheront lors des changements d'état, à la classe Presenter, à laquelle il souscrira (ou observera). Lorsque le présentateur reçoit la notification d'événement, il exécute toute logique, puis le présentateur modifie la vue en conséquence.
Il n'y aura qu'une seule de chaque classe Model en mémoire, mais il pourrait y avoir de nombreuses instances de BaseForm et donc de BaseFormPresenter. Cela résoudrait mon problème de synchronisation de chaque instance de BaseForm avec le même modèle de données.
Des questions:
Quelle couche doit stocker des éléments comme le dernier bouton enfoncé, afin que je puisse le mettre en surbrillance pour l'utilisateur (comme dans un menu CSS) entre les formulaires?
Veuillez critiquer cette conception. Merci de votre aide!