Comment modéliser ceci dans OO

Question

J'ai une boîte de dialogue d'interface utilisateur quelque chose comme ceci: Vous devez choisir un livre dans une liste. En option, vous pouvez choisir un éditeur (une autre classe) dans une liste ou entrer le nom de l'éditeur sous la forme d'une chaîne.

Je pense que cela me donne 3 types comme la sortie de la boîte de dialogue.

1. livre
2. livre avec l'éditeur de classe
3. livre avec l'éditeur-string

Comment décririez-vous ce modèle dans les objets? Il me semble que le fait d'avoir un livre de classe de base, puis deux sous-classes pour le nom de l'éditeur et de l'éditeur est le bon choix. Existe-t-il des alternatives, en favorisant peut-être une composition qui donnerait un meilleur modèle?

---

Je vais essayer d'expliquer un peu plus. Un livre n'a pas besoin d'éditeur. L'objet éditeur n'est pas identique à un nom d'éditeur saisi en tant que chaîne.

Vous devez
-choisir un livre d'une liste existante

Vous pouvez une des options suivantes
-choisir un éditeur dans une liste existante ou
-on peut entrer un nom d'éditeur ou
- vous ne pouvez rien renseigner sur l'éditeur

Answer 1

Je vais essayer d'expliquer un peu plus. Un livre n'a pas besoin d'éditeur. L'objet éditeur n'est pas identique à un nom d'éditeur entré en tant que chaîne.

Vous devez -choisir un livre d'une liste existante

Vous pouvez une des options suivantes -choisir un éditeur dans une liste existante ou peut entrer un -you nom de l'éditeur ou pouvez remplir rien -you à propos de l'éditeur

Toujours appelle un objet de résultat personnalisé. Vous avez maintenant trois champs un objet livre, un objet Publisher et une chaîne Publisher. Vous le passez ensuite au code qui peut le traiter intelligemment. Vous pouvez ajouter des méthodes pour répondre aux besoins de traitement personnalisés. Mais à la fin c'est un résultat spécialisé de ce dialogue et ne devrait pas être un sous-champ de livre ou d'éditeur ou tout autre objet.

Si le livre n'est rien, vous savez que vous avez une erreur parce que vous avez besoin d'un livre. Vous avez également quatre combinaisons d'objet Publisher et Publisher_String à gérer. Cela m'indique que vous avez besoin d'une classe pour traiter spécifiquement du résultat.

Answer 2

Le numéro deux serait mon approche.

Je voudrais avoir une classe pour Publisher avec une propriété appelée Nom, avec toutes les autres propriétés nécessaires pour décrire un éditeur.

Puis j'aurais une classe pour livre avec des propriétés pour le décrire, avec une propriété de type Publisher.

Si l'utilisateur entre un nouvel éditeur sous forme de chaîne, créez un nouvel objet Publisher.

Si l'utilisateur n'entre pas dans un éditeur, laissez la propriété NULL. Cela satisfera à la condition que le livre n'ait pas d'éditeur. Alternativement, vous pourriez avoir un éditeur avec le nom "Pas d'éditeur" mais je pense que cela va trop loin de votre façon d'éviter les nulls.

Answer 3

Je ne crée une classe d'éditeur pour hériter du livre, depuis Publisher est pas un livre, il est des métadonnées au sujet un livre. Cependant, la Bible hériterait du Livre.

Mon conseil serait de créer une propriété Publisher sur le livre. Cet éditeur pouvait être de type IPublishInformation, et l'éditeur de chaîne pouvait utiliser une classe NamedPublisher {string Name}, en implémentant IPublishInformation.

C'est ce que je pense de toute façon!

Answer 4

Je pense qu'il est difficile de prendre une décision de conception basée uniquement sur cette boîte de dialogue. Par exemple, choisissez-vous parmi un ensemble de livres existants? Dans ce cas, que se passe-t-il si l'utilisateur entre un éditeur qui n'existe pas?Dans ce cas, vous ne souhaiterez peut-être pas renvoyer une instance de n'importe quelle classe Book, mais déclencher une sorte d'exception.

Est-ce que tous les livres de votre bibliothèque ont des éditeurs? Si oui, alors je suis d'accord avec @Bob que vous pourriez faire une classe Publisher, et avoir une classe Book contient une instance d'un objet Publisher. Si seulement quelques livres ont des éditeurs, alors vous pourriez aller avec le modèle d'héritage que vous décrivez, mais je réduirais les options 2 et 3 en un seul choix (encore en utilisant un objet Publisher) car sinon vous pourriez vous retrouver avec deux instances identiques livre qui sont des objets de différents types (un où l'utilisateur a entré l'éditeur sous forme de chaîne, et une fois en choisissant dans la liste).

--Phil

Answer 5

Du point de vue OO, les relations HAS-A résoudre ce problème mieux que les relations IS-A dans ce cas. Un livre HAS-A éditeur (1: 1) et un éditeur HAS-A une liste de livres qu'il publie (1: plusieurs). Créez une classe Book qui contient une référence à un éditeur et une classe Publisher qui a une liste de références à Books. De plus, l'éditeur a-Une chaîne que vous pouvez utiliser pour localiser un éditeur spécifique

Answer 6

Je dois être en désaccord avec cette déclaration dans le dernier paragraphe:

Il me semble que l'avoir une base de classe livre , puis deux sous-classes pour l'éditeur et le nom de l'éditeur est le bon choix.

Les sous-classes sont utilisées pour représenter la relation "est-ce-de-type". (Le vieux stéréotype fatigué est une classe Fruit, avec Apple et Orange comme sous-classes.) Un exemple plus réaliste serait un système de paie avec une classe Employee, spécialisée par les classes HourlyEmployee et SalariedEmployee. Dans chaque cas, la sous-classe représente une catégorie spécifique dans la superclasse. Par contre, un éditeur n'est pas une sorte de livre. Un meilleur modèle serait d'avoir une classe Book et une classe Publisher, avec une relation many-to-one entre eux (un livre a un seul éditeur, mais un éditeur peut produire plusieurs livres). Un livre a de nombreux attributs potentiels, tels que le titre, l'ISBN, l'éditeur et l'auteur; Les attributs potentiels d'un éditeur comprennent le nom et l'adresse de l'entreprise (éventuellement plusieurs adresses) et une liste de livres publiés. En fonction de ce que vous essayez de modéliser, vous pouvez également avoir besoin d'une classe Auteur, mais cela ne correspond pas à la portée de votre question initiale.

Answer 7

Si vous supposez que les livres peuvent avoir plusieurs éditeurs. Ensuite, je vais retourner un BookSelectonResult avec deux propriétés. Un ensemble à un livre et un autre à l'éditeur sélectionné. Cette réponse suppose également que vous avez une classe de livre, une classe d'éditeur et une classe de collection pour chacun.

Le point du dialogue est de retourner ce que l'utilisateur a sélectionné. C'est une "chose" unique qui mérite sa propre classe. Si tout ce que vous faisiez est de retourner un seul livre ou un seul éditeur, alors utiliser la classe originale directement serait ok. Mais ici, vous avez plusieurs possibilités dans les résultats, ce qui appelle une classe de résultats unique.

L'autre considération est de savoir à quel point ce dialogue est trivial? Par exemple choisir un nom de fichier pour ouvrir un livre. L'existence du nom de fichier est éphémère ce que vous voulez que le livre soit stocké dans votre système. La même chose pour le résultat de la sélection d'un livre et d'un éditeur. Si vous aviez déjà un autre objet pour contenir le résultat (comme une liste d'extraction), je suggère de ne pas vous embêter avec des méthodes ou des classes spéciales. Regroupez la boîte de dialogue dans un objet Command et renvoyez simplement le résultat dans les membres de la classe de dialogue. Puis traiter le résultat à l'endroit où ils sont finalement stockés.

Dans mon logiciel de FAO, je le fais souvent avec la boîte de dialogue qui manipule les options de configuration au lieu d'utiliser mon architecture élaborée model-view-presenter. La raison pour laquelle je peux m'en tirer est que lorsqu'un utilisateur clique sur un élément ou exécute une action, le contrôleur de l'interface utilisateur exécute un objet Command qui manipule ensuite le modèle. Tout passe par l'objet de commande dans ma configuration. Donc, pour les boîtes de dialogue triviales, je les regroupe simplement avec des objets de commande qui utilisent la boîte de dialogue plutôt que de créer l'ensemble de la couche MVP.

En fin de compte, c'est un appel de jugement.

Answer 8

Essayez cette (C#):

Class Book 
{ 
    public string Name; 
    public List<Publisher> publishers = new List<Publishers>; 

    Book() 
    { 
     // Load publishers array with relevant instances of Publisher class... 
    } 
} 

Class Books 
{ 
    private List<Book> books = new List<Book>; 
    public Books() 
    { 
     // Load books array with all books... 
    } 

    public List<Book> GetBook (string publisher) 
    { 
     List<Book> retVal = new List<Book>; 
     foreach (Book item in books) 
     { 
     if (item.Publisher.Name == publisher) 
     { 
      retVal.Add(item); 
     } 
     } 
    } 

    public List<Book> GetBook (Publisher publisher) 
    { 
     List<Book> retVal = new List<Book>; 
     foreach (Book item in books) 
     { 
     if (item.Publisher.Name == publisher.Name) 
     { 
      retVal.Add(item); 
     } 
     } 
    } 
} 

Class Publisher 
{ 
    public string Name; 
}