Quão ruim é ter dois métodos com o mesmo nome, mas diferentes assinaturas em duas classes?

4

Eu tenho um problema de design relacionado a uma interface pública, os nomes dos métodos e o entendimento da minha API e código.

Eu tenho duas classes assim:

class A:
    ...
    function collision(self):
        ....

...

class B:
    ....
    function _collision(self, another_object, l, r, t, b):
        ....

A primeira classe tem um método público chamado colisão , e o segundo tem um método privado chamado _ colisão . Os dois métodos diferem no tipo e número de argumentos.

Como exemplo, digamos que _ colisão verifica se o objeto está colidindo com outro objeto com certas condições l , r , t , b (colida do lado esquerdo, lado direito, etc) e retorna verdadeiro ou falso . O método público colisão , por outro lado, resolve todas as colisões do objeto com outros objetos.

Os dois métodos têm o mesmo nome porque acho melhor evitar sobrecarregar o design com nomes diferentes para métodos que fazem quase a mesma coisa, mas em contextos e classes distintos.

Isso está claro o suficiente para o leitor ou eu devo mudar o nome do método?

    
por Super User 22.10.2013 / 22:29
fonte

3 respostas

21

Essas funções têm a ver com colisões, mas o que elas fazem é muito diferente, então dar nomes que descrevam mais claramente o que elas realmente farão será mais fácil para futuros desenvolvedores entenderem a diferença sem ter que olhar para a lógica interna.

O método que verifica se o objeto está colidindo com outro objeto pode ser chamado de checkForCollision .

O método que resolve as colisões do objeto com outros objetos pode ser chamado de resolveCollisions ou handleCollisions .

Quando duas funções fazem quase a mesma coisa, muitas vezes é o melhor tempo para dar nomes mais específicos para que a diferença seja clara.

    
por 22.10.2013 / 22:59
fonte
3

Eu diria que não há nada de errado com isso. Sobrecarga de método é uma prática bastante padrão, por várias razões. Se você tem a mesma funcionalidade exata, apenas para duas séries diferentes de parâmetros, usar exatamente o mesmo nome faz todo o sentido, e também ajuda a esclarecer que a lista de parâmetros deve ser aproximadamente a única diferença real entre as duas funções. Isso facilita o código em idiomas que o suportam.

Quanto a ter essas duas funções fazendo duas coisas um pouco diferentes (A.colisão () sendo mais geral que B._colisão ()), neste caso, é bom por duas razões:

  1. Eles não estão realmente sobrecarregados. "colisão" < > "_collision" (a menos que a Python esteja fazendo algo aqui que eu não saiba).

  2. Eles não estão realmente sobrecarregados. classe A < > classe B. Mesmo se eles tivessem o mesmo nome básico, outros programadores deveriam ser capazes de distinguir entre funções em duas classes diferentes com bastante facilidade (a menos que uma esteja subclassificando outra). Classes diferentes, obviamente, tendem a fazer as coisas de maneira diferente.

por 28.10.2013 / 13:41
fonte
3

Nas palavras do leigo:

  1. Os nomes dos métodos devem ser verbos , então ambos os nomes são inadequados.
  2. Quando você lhes der nomes apropriados (com um verbo), é improvável que os dois nomes do método coincidam.
  3. Mesmo se os dois métodos tivessem o mesmo nome, eles estão em classes diferentes e não há como confundi-los porque eles têm namespaces diferentes.
  4. Não há regras de estilo (ou qualquer outra) declarando que duas classes ou interfaces distintas não podem ter métodos com o mesmo nome, mesmo que tenham a mesma assinatura (lista de parâmetros).

Por exemplo

// there's absolutely no problem with this totally unrelated (or related) classes:
databaseClient.connect();
odbcSource.connect();
navii.connect();
fireHose.connect();

Resposta curta: não há nada de errado com isso.

    
por 28.10.2013 / 17:37
fonte