Ao projetar um protocolo, é melhor para um método aceitar um único objeto de um tipo específico ou uma matriz?

5

Atualmente, estou projetando um protocolo para uso interno, por isso não faz grande diferença neste caso específico, mas me fez pensar:

É melhor para um método aceitar um único objeto de um tipo específico ou uma matriz de objetos, com a documentação especificando o tipo que ele conterá? Obviamente, o array permite uma maior flexibilidade na chamada do método, mas a especificação de um tipo fornece ao programador maior clareza sobre o que o método estará fazendo.

Por exemplo, meu protocolo tem um único método (até agora), chamado recieveDroppedItems :. Ele precisa aceitar uma ou várias NSURLs, que apontam para os arquivos soltos no remetente.

Agradecemos antecipadamente por qualquer conselho que você tenha! : D

    
por vilhalmer 02.05.2011 / 18:46
fonte

5 respostas

3

Não há uma resposta geral para a sua pergunta, mas deixe-me fornecer uma ao seu exemplo para apontar alguns princípios que geralmente se aplicam.

Nota: eu falarei daqui em diante de "interfaces" ao invés de "protocolos", não só porque é mais comum o nome em outras línguas, mas também porque eu realmente quero dizer interfaces de uma maneira mais abstrata, como em " a definição de como algo pode ser interfaceado com ".

Ao projetar uma interface, você deve projetá-la, como se não tivesse meios de implementá-la, mas sim confiar em outra pessoa, a quem só será possível comunicar suas necessidades por meio de sua definição.
Se você assumir esse cenário, verá que deseja que uma interface seja muito clara (caso contrário, a implementação pode não ser projetada para fazer o que você espera) e muito fácil de implementar (caso contrário, a implementação pode falhar em fazer o que você espera).

Agora, no contexto em que você depende do serviço abstraído da interface projetada, você deve ter sido capaz de tomar várias decisões importantes, que você não deve encaminhar ao implementador para não forçá-las a ultrapassar o princípio da responsabilidade única. , nem provocar duplicação de código. Em vez disso, você precisa tomar essas decisões e transmiti-las na sua invocação de método.
Neste exemplo, você pode ter:

  • descobri se alguns itens podem ser processados em lote - supondo que você espera alguma vantagem em fazê-lo
  • conseguiu filtrar duplicados - supondo que seu sistema possa produzir qualquer um em primeiro lugar

E assim (sob ambas as suposições) seu contrato com o implementador deve ser "você deve ser capaz de processar um lote de URLs únicos".

Você dificilmente pode transportar este contrato sem ambiguidade sem documentação, mas você pode tentar, por exemplo, por nomes de métodos. IMHO receiveDroppedItems não é muito expressivo, porque item é realmente ambíguo e receber também está em uma linguagem baseada na passagem de mensagens.
Eu chamaria de processDroppedURLs . Não é mais, mas realmente diz o que se espera que aconteça. Se me pedem para implementar tal método, eu penso "Ah, ok, então eu sou esperado para processar uma coleção de URLs descartados" (assumindo que eu sei o que caiu significa nesse contexto, eu sei tudo Eu preciso). Mesmo que o tipo da coleção possa ser definido como algo tão vago quanto NSFastEnumeration , eu esperaria que for...in gerasse NSURL s. Quanto à informação de exclusividade, eu provavelmente prefiro colocar isso na documentação, em vez do nome do método, porque não é tão vital.

Para resumir: Você quer interfaces limpas, concisas e quase minimalistas com nomes de métodos expressivos, que criam barreiras de abstração entre o escopo atual do cliente e o escopo do serviço abstraído, que são claras e simples de ambos os lados.

    
por 02.05.2011 / 21:47
fonte
4

Depende da sobrecarga de envio de uma mensagem e do quanto você pode simplificar lidando com apenas uma notificação de cada vez.

Se você tiver uma sobrecarga alta (por exemplo, protocolo de rede) e for bastante fácil lidar com várias notificações (o que certamente poderia ser o caso ao enviar vários URLs de uma só vez), é possível permitir múltiplos.

Se você tem pouca sobrecarga (por exemplo, essas são mensagens trocadas dentro de uma única máquina), há menos motivação para agrupar as mensagens.

    
por 02.05.2011 / 19:08
fonte
1

Odeio dizer, mas depende.

Um caso que vi em uso comum é o J2EE HttpServletRequest.getParameterList() . Ele retorna um Map<String, String[]> . Razão de ser, certos elementos de formulário HTML, como caixas de seleção, podem ter vários valores. Ou há vários elementos com o mesmo nome, mas com valores diferentes (provavelmente programação incorreta, mas há casos válidos). Nesse caso, os projetistas da API decidiram que os valores múltiplos eram comuns o suficiente para garantir a obrigatoriedade da matriz em todas as chamadas.

Veja as formas mais comuns pelas quais sua API será chamada. Se você está recebendo vários valores a maior parte do tempo, provavelmente vale a pena fazer. Outra opção poderia ser ter dois métodos - um para um valor único e outro para múltiplos.

    
por 02.05.2011 / 19:33
fonte
1

O método pode ter uma lista de argumentos de tamanho variável; então ele pode aceitar apenas um ou mais do que no objeto (sem a necessidade de criar um array para armazená-los).

    
por 02.05.2011 / 19:47
fonte
-1

Depende da linguagem que você usa porque alguns idiomas não permitem matrizes heterogêneas, a menos que suas funções só aceitem listas de strings ou listas de outras coisas ou você goste de transmitir tudo sobre o local, sua única opção é especificar algum produto digite e use isso como entrada. Além disso, em geral, os tipos explícitos de entradas e saídas são melhores práticas.

    
por 02.05.2011 / 19:10
fonte