Como modelar isso em OO

votos
2

Eu tenho uma coisa UI-de diálogo como esta: Você deve escolher um livro a partir de uma lista. Opcionalmente, você pode escolher uma editora (outra classe) a partir de uma lista ou digite o nome do editor como como uma string.

Eu acho que isso me dá 3 tipos como a saída do diálogo.

  1. livro
  2. livro com a editora de classe
  3. livro com a editora-string

Como você modelar isso em objetos? Parece-me que a ter um livro de classe base, e depois duas subclasses para editor e nome do editor é a escolha correta. Existem alternativas, talvez favorecendo composição que daria um modelo melhor?


Vou tentar explicar um pouco mais. Um livro não precisa ter um editor. O objeto editor não é o mesmo que um nome de editor introduzido como uma cadeia.

Você deve
-Escolha um livro a partir de uma lista existente

Pode um dos seguintes
-Escolha um editor de uma lista existente ou
-você pode digitar um nome de editor ou
-você pode preencher nada sobre o editor

Publicado 09/12/2008 em 20:58
fonte usuário
Em outras línguas...                            


8 respostas

votos
5

O número dois seria a minha abordagem.

Eu teria uma classe para o Publisher com uma propriedade chamada Nome, juntamente com quaisquer outras propriedades necessárias para descrever uma editora.

Então eu teria uma classe para o livro com propriedades para descrevê-lo, juntamente com uma propriedade do tipo Publisher.

Se o usuário digitar um novo editor como uma string, criar um novo objeto Publisher.

Se o usuário não inserir um editor, deixar o nulo propriedade. Que irá satisfazer a condição de que o livro não tem editores. Alternativamente, você poderia ter editora com o nome "Nenhum editor", mas acho que está indo longe demais fora do seu caminho para evitar nulos.

Respondeu 09/12/2008 em 21:01
fonte usuário

votos
2

Devo discordar desta declaração no último parágrafo:

Parece-me que a ter um livro de classe base, e depois duas subclasses para editor e nome do editor é a escolha correta.

Subclasses são usados ​​para representar "é-um-tipo de" relacionamento. (O velho estereótipo cansado é uma classe de frutas, com maçã e laranja como subclasses.) Um exemplo mais realista seria um sistema de folha de pagamento com uma classe Employee, especializada por classes EmpregadoHorista e SalariedEmployee. Em cada caso, a subclasse representa uma categoria específica dentro da superclasse.

Em contraste, um editor não é um tipo de livro. Um modelo melhor seria ter uma classe Book e uma classe Publisher, com um relacionamento muitos-para-um entre eles (um livro tem um único editor, mas um editor pode produzir vários livros).

Um livro tem muitos atributos potenciais, como o título, ISBN, editor e autor; atributos potenciais de um editor incluir o nome e endereço da empresa (possivelmente vários endereços) e uma lista de livros publicados.

Dependendo do que você está tentando modelar, você também pode precisar de uma classe de Autor, mas isso é fora do âmbito da sua pergunta original.

Respondeu 09/12/2008 em 21:21
fonte usuário

votos
2

De uma perspectiva OO, tem-um relacionamento resolver este problema melhor do que relacionamentos IS-A neste caso. Um livro tem-A editora (1: 1) e um editor tem-A lista de livros que publica (1: muitos). Crie uma classe livro que contém uma referência a um editor e uma classe Publisher que tem uma lista de referências a livros. Além disso, a editora tem-A corda que você pode usar para localizar um editor específico

Respondeu 09/12/2008 em 21:19
fonte usuário

votos
1

Vou tentar explicar um pouco mais. Um livro não precisa ter um editor. O objeto editor não é o mesmo que um nome de editor introduzido como uma cadeia.

Você deve -Escolha um livro a partir de uma lista existente

Pode um dos seguintes -Escolha um editor de uma lista existente ou -você pode digitar um nome de editor ou -você pode preencher nada sobre o editor

Ainda exige um objeto de resultado personalizado. Agora você tem três campos de um objeto livro, um objeto Publisher, e uma série Publisher. Você, então, passá-lo para o código que pode lidar com isso de forma inteligente. Você pode adicionar métodos para atender às necessidades de processamento personalizado. Mas no final é um resultado especializada de que o diálogo e não deve haver alguma subcampo de livro ou editor ou qualquer outro objeto.

Se o livro não é nada que você sabe que tem um erro porque você precisa de um livro. Você tem quatro combinações de objeto do Publisher e Publisher_String para lidar com tão bem. Isso indica para mim que você precisa de uma classe para lidar especificamente com o resultado.

Respondeu 09/12/2008 em 21:50
fonte usuário

votos
1

Eu não iria criar uma classe Publisher para herdar Livro, desde Publisher não é um livro, é informações de metadados sobre um livro. A Bíblia, porém, herdaria Book.

Meu conselho seria a criação de uma propriedade Publisher no Livro. Este editor pode ser do tipo IPublishInformation, eo editor corda poderia usar um {string Nome} class NamedPublisher, implementando IPublishInformation.

Esse é o meu pensamento de qualquer maneira!

Respondeu 09/12/2008 em 21:12
fonte usuário

votos
0

Tente isto (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;
}
Respondeu 09/12/2008 em 22:00
fonte usuário

votos
0

Se você está assumindo que os livros podem ter vários editores. Então eu vou retornaria um BookSelectonResult com duas propriedades. Um conjunto de um livro e outro conjunto para o Publisher selecionado. Esta resposta também assumir que você tem uma classe livro, uma classe editor, e uma classe de coleção para cada um.

O ponto do diálogo é retornar o que o usuário selecionado. Que é uma "coisa" única para que merece a sua própria classe. Se tudo o que estavam fazendo é retornar um único livro ou um único editor, em seguida, usando a classe original diretamente seria ok. Mas aqui você tem várias possibilidades dos resultados para que apela para uma classe resultado único.

A outra consideração é o quão trivial é este diálogo? Por exemplo escolhendo um nome de arquivo para abrir um livro. O nome do arquivo existência é fugaz o que você quer é o livro para ser armazenado em seu sistema. O mesmo para o resultado da seleção de um livro e uma editora. Se você tivesse um outro objeto para segurar o resultado já (como uma lista de verificação para fora), então eu sugiro que não se preocupar com quaisquer métodos especiais ou classes. Pacote de diálogo em um objeto de comando e apenas retornar o resultado nos membros da classe de diálogo. Em seguida, processar o resultado para onde eles estão finalmente armazenado.

Na minha software CAM eu faço isso muitas vezes com o diálogo que manipular as opções de configuração em vez de usar o meu elaborada arquitetura Model-View-apresentador. A razão que eu posso fugir com isso é porque quando um usuário clica em um item ou executar uma ação, o controlador de UI executa um objeto de comando que, em seguida, manipula o modelo. Tudo passa por objeto de comando na minha configuração. Assim, para diálogos triviais Eu apenas empacotá-los com objetos de comando que usa a caixa de diálogo, em vez de criar toda a camada de MVP.

Em última análise, é um julgamento.

Respondeu 09/12/2008 em 21:35
fonte usuário

votos
0

Eu acho que é difícil fazer uma decisão de projeto com base apenas neste diálogo. Por exemplo, se você escolher a partir de um conjunto de livros existentes? Nesse caso, e se o usuário digita um editor que não existe? Neste caso, você pode não querer retornar uma instância de qualquer classe Livro em tudo, mas levantar algum tipo de exceção.

Será que todos os livros em seu caso tem editoras? Se assim for, então eu concordo com @Bob que você poderia fazer uma classe Publisher, e ter uma classe Book conter uma instância de um objeto Publisher. Se apenas alguns livros têm Publishers, então você pode ir com o modelo de herança que você descreve, mas eu entraria em colapso opções 2 e 3 em uma única escolha (novamente usando um objeto Publisher) porque senão você pode acabar com duas instâncias do mesmo livro que são objetos de diferentes tipos (aquele em que o usuário entrou no publisher como uma string, e uma vez por escolher da lista).

--Phil

Respondeu 09/12/2008 em 21:15
fonte usuário

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