Cómo modelar esto en OO

votos
2

Tengo un diálogo de IU algo así: debes elegir un libro de una lista. Opcionalmente, puede elegir un publicador (otra clase) de una lista o ingresar el nombre del editor como una cadena.

Creo que esto me da 3 tipos como salida del diálogo.

  1. libro
  2. libro con editor-clase
  3. libro con cadena editorial

¿Cómo modelarías esto en objetos? Me parece que tener una clase base de libro y luego dos subclases para el nombre del editor y del editor es la opción correcta. ¿Hay alguna alternativa, quizás favoreciendo la composición que daría un mejor modelo?


Trataré de explicar un poco más. Un libro no necesita tener un editor. El objeto editor no es lo mismo que un nombre de editor ingresado como una cadena.

Debe
elegir un libro de una lista existente

Puede
elegir una de las siguientes opciones: elegir un editor de una lista existente o
-puede introducir un nombre de editor o
-no puede completar nada sobre el editor

Publicado el 09/12/2008 a las 20:58
fuente por usuario
En otros idiomas...                            


8 respuestas

votos
5

El número dos sería mi enfoque.

Tendría una clase para Publisher con una propiedad llamada Name, junto con cualquier otra propiedad necesaria para describir a un editor.

Luego tendría una clase de libro con propiedades para describirlo, junto con una propiedad de tipo Publisher.

Si el usuario ingresa un nuevo editor como una cadena, cree un nuevo objeto de Publisher.

Si el usuario no ingresa un editor, deje la propiedad nula. Eso satisfará la condición de que el libro no tenga editores. Alternativamente, podría tener un editor con el nombre "Sin editor", pero creo que eso se está yendo demasiado lejos para evitar los valores nulos.

Respondida el 09/12/2008 a las 21:01
fuente por usuario

votos
2

Debo estar en desacuerdo con esta afirmación en el último párrafo:

Me parece que tener una clase base de libro y luego dos subclases para el nombre del editor y del editor es la opción correcta.

Las subclases se utilizan para representar la relación "es una especie de". (El viejo y cansado estereotipo es una clase Fruit, con Apple y Orange como subclases.) Un ejemplo más realista sería un sistema de nómina con una clase Employee, especializada por las clases HourlyEmployee y SalariedEmployee. En cada caso, la subclase representa una categoría específica dentro de la superclase.

Por el contrario, un editor no es un tipo de libro. Un mejor modelo sería tener una clase Book y una clase Publisher, con una relación muchos a uno entre ellos (un libro tiene un único editor, pero un editor puede producir varios libros).

Un libro tiene muchos atributos potenciales, como título, ISBN, editor y autor; los atributos potenciales de un editor incluyen el nombre comercial y la dirección (posiblemente varias direcciones) y una lista de libros publicados.

Dependiendo de lo que está tratando de modelar, también puede necesitar una clase de Autor, pero eso está fuera del alcance de su pregunta original.

Respondida el 09/12/2008 a las 21:21
fuente por usuario

votos
2

Desde una perspectiva OO, las relaciones HAS-A resuelven mejor este problema que las relaciones IS-A en este caso. Un libro HAS-A editor (1: 1) y un editor HAS-Una lista de libros que publica (1: muchos). Cree una clase Book que contenga una referencia a un Publisher y una clase Publisher que tenga una lista de referencias a Books. Además, la cadena Publisher HAS-A que puede usar para ubicar un editor específico

Respondida el 09/12/2008 a las 21:19
fuente por usuario

votos
1

Trataré de explicar un poco más. Un libro no necesita tener un editor. El objeto editor no es lo mismo que un nombre de editor ingresado como una cadena.

Debe elegir un libro de una lista existente

Puede elegir una de las siguientes opciones: elegir un editor de una lista existente o -puede introducir un nombre de editor o -no puede completar nada sobre el editor

Aún requiere un objeto de resultado personalizado. Ahora tiene tres campos: un objeto de libro, un objeto de editor y una cadena de editor. Luego lo pasa al código que puede manejarlo inteligentemente. Puede agregar métodos para abordar las necesidades de procesamiento personalizado. Pero al final es un resultado especializado de ESE cuadro de diálogo y no debe ser un subcampo del libro o editorial o cualquier otro objeto.

Si el libro no es nada, usted sabe que recibió un error porque necesita un libro. También tiene cuatro combinaciones de Publisher Object y Publisher_String para tratar. De esto me indica que necesita una clase para tratar específicamente con el resultado.

Respondida el 09/12/2008 a las 21:50
fuente por usuario

votos
1

No crearía una clase de editor para heredar el libro, ya que Publisher no es un libro, es información de metadatos sobre un libro. La Biblia, sin embargo, heredaría el Libro.

Mi consejo sería crear una propiedad de editor en el libro. Este publicador podría ser de tipo IPublishInformation, y el editor de cadenas podría usar una clase NamedPublisher {string Name}, implementando IPublishInformation.

¡Eso es lo que pienso de todos modos!

Respondida el 09/12/2008 a las 21:12
fuente por usuario

votos
0

Pruebe esto (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;
}
Respondida el 09/12/2008 a las 22:00
fuente por usuario

votos
0

Si está asumiendo que Books puede tener varios editores. Luego devolveré un BookSelectonResult con dos propiedades. Un conjunto a un Libro y otro conjunto al Editor seleccionado. Esta respuesta también supone que tiene una clase de libro, una clase de editor y una clase de colección para cada una.

El objetivo del Diálogo es devolver lo que el usuario seleccionó. Esa es una "cosa" única, así que merece su propia clase. Si todo lo que hace es devolver un solo libro o una sola editorial, entonces usar la clase original directamente sería correcto. Pero aquí tiene múltiples posibilidades en los resultados, por lo que requiere una clase de resultado única.

La otra consideración es cuán trivial es este diálogo? Por ejemplo, elegir un nombre de archivo para abrir un libro. La existencia del nombre de archivo es fugaz, lo que desea es que el libro se almacene en su sistema. Lo mismo para el resultado de seleccionar un libro y un editor. Si tuviera otro objeto para mantener el resultado ya (como una lista de verificación), le sugiero que no se moleste con ningún método o clase especial. Agrupe el diálogo en un objeto Command y simplemente devuelva el resultado en los miembros de la clase de diálogo. Luego procese el resultado hasta donde finalmente se almacenan.

En mi software CAM lo hago a menudo con el diálogo que manipula las opciones de configuración en lugar de usar mi arquitectura elaborada de modelo-vista-presentador. La razón por la que puedo salirse con la suya es porque cuando un usuario hace clic en un elemento o realiza una acción, el controlador de la UI ejecuta un objeto Command que luego manipula el modelo. Todo pasa por el Objeto de Comando en mi configuración. Entonces, para diálogos triviales, simplemente los combino con objetos de comando que usan el diálogo en lugar de crear toda la capa de MVP.

En definitiva, es una decisión de juicio.

Respondida el 09/12/2008 a las 21:35
fuente por usuario

votos
0

Creo que es difícil tomar una decisión de diseño basada solo en este diálogo. Por ejemplo, ¿está eligiendo de un conjunto de libros existentes? En ese caso, ¿qué pasa si el usuario ingresa un editor que no existe? En este caso, es posible que no desee devolver una instancia de ninguna clase de Libro, pero plantee algún tipo de excepción.

¿Todos los libros en su caso tienen editores? Si es así, entonces estoy de acuerdo con @Bob de que podría crear una clase de editor, y tener una clase de libro que contenga una instancia de un objeto de editor. Si solo algunos libros tienen Publishers, entonces podría ir con el modelo de herencia que describe, pero colapsaría las opciones 2 y 3 en una sola opción (nuevamente usando un objeto Publisher) porque de lo contrario podría terminar con dos instancias de la misma libro que son objetos de diferentes tipos (uno donde el usuario ingresó al editor como una cadena, y una vez al elegir de la lista).

--Phil

Respondida el 09/12/2008 a las 21:15
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more