Comment gérer les classes dérivées dans l'interface utilisateur sans déclarations switch lors de l'utilisation de MVC/MCP?

Question

Je suis en train d'utiliser un modèle MVC/MCP pour mon application C# (WinForms).

Dans la logique métier, j'ai des classes dérivées comme

public abstract class Item
{
    public abstract double CalculatePrice();
    ...
}

public class Nail : Item
{
    ...
}

public class Car : Item
{
    ...
}

Pour la logique métier, le type dérivé d'un objet n'a pas d'importance. Je peux toujours appeler des méthodes comme CalculatePrice() peu importe le type réel de l'objet.

Mais comment gérer de tels objets dans l'interface utilisateur (WinForms) lorsque je les présente à l'utilisateur ? (et bien sûr, une Car est présentée différemment qu'un Nail)

• Je ne veux pas avoir de grande déclaration switch dans l'interface utilisateur / le contrôleur pour gérer tous les types d'objets.

• Je ne veux pas implémenter une

  méthode abstract double ShowMeAtUI()

  dans la classe de l'objet, car il s'agit de la logique métier et elle ne devrait pas se soucier des éléments de l'interface utilisateur.

Alors, quelle est la meilleure façon propre de concevoir cela.

Merci d'avance!!

Answer 1

Il me semble que vous avez besoin d'un motif de stratégie pour les vues, n'est-ce pas ?

Une façon dont j'ai résolu cela en utilisant MVP est en créant des sous-vues UserControl. J'utiliserai un Présentateur même pour la sous-vue. Si vous pouvez modulariser votre vue principale en composants UserControl, ou si cela a du sens, alors cela peut être une option.

Vous pourriez implémenter un dictionnaire pour savoir quelle sous-vue ajouter au conteneur du contrôle parent.

Ou, si je me souviens bien, j'ai utilisé un dictionnaire dont la valeur était une délégation pour afficher une sous-vue spécifique donnée le contrôle parent.

Answer 2

Je ne comprends pas pourquoi vous avez besoin de la méthode abstraite ComputePrice. Le prix d'un objet est probablement dans les données. Si c'est le cas, tout ce dont vous avez besoin est une propriété Prix dans la classe de base Item pour obtenir le prix de n'importe quelle instance d'objet.

Cela fonctionnerait de la même manière pour d'autres champs communs tels que le nom, la description, le volume des ventes, etc. Ensuite, similairement à la propriété Prix, vous ajouteriez une propriété (Nom, Description, VolumeDesVentes) à la classe de base Item.

Peut-être que le prix d'un objet n'est pas explicitement dans les données et doit être calculé. Si c'est le cas, je ne comprends toujours pas pourquoi ce calcul ne pourrait pas être dans la classe de base. Par exemple, si le prix de vente doit être réduit en fonction du client. Dans ce cas, la classe Item applique les règles de réduction et le client qui effectue l'achat.

Peut-être pourriez-vous expliquer pourquoi ComputePrice doit être une abstraction et/ou donner d'autres exemples d'abstractions qui nécessiteraient une implémentation spécifique dans chaque classe dérivée (Clou, Voiture).