Quanto è brutto avere due metodi con lo stesso nome ma diverse firme in due classi?

Question

Quanto è brutto avere due metodi con lo stesso nome ma diverse firme in due classi?

#1 da (21 voti)
#2 da (3 voti)
#3 da (3 voti)

4

Ho un problema di progettazione relativo a un'interfaccia pubblica, i nomi dei metodi e la comprensione della mia API e del codice.

Ho due classi come questa:

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

...

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

La prima classe ha un metodo pubblico denominato collisione e il secondo ha un metodo privato chiamato _ collisione . I due metodi differiscono per tipo di argomento e numero.

Come esempio, supponiamo che _ collisione controlli se l'oggetto è in collisione con un altro oggetto con determinate condizioni l , r , t , b (si scontrano sul lato sinistro, sul lato destro, ecc.) e restituisce vero o falso . Il metodo pubblico collisione , d'altra parte, risolve tutte le collisioni dell'oggetto con altri oggetti.

I due metodi hanno lo stesso nome perché penso che sia meglio evitare di sovraccaricare il design con nomi diversi per metodi che fanno quasi la stessa cosa, ma in contesti e classi distinti.

Questo è abbastanza chiaro per il lettore o dovrei cambiare il nome del metodo?

design design-patterns class-design software class-diagram

posta Super User 22.10.2013 - 22:29

fonte

3 risposte

Leggi altre domande sui tag design design-patterns class-design software class-diagram

Problema di progettazione dell'API: per REST o non per REST Perché il compilatore Java decide se è possibile chiamare un metodo basato sul tipo "di riferimento" e non sul tipo "oggetto" effettivo?

score 21 · Answer 1

Queste funzioni hanno entrambe a che fare con le collisioni, ma ciò che fanno è molto diverso, quindi dare loro nomi che descrivano più chiaramente ciò che effettivamente fanno renderà più facile per i futuri sviluppatori capire la differenza senza dover guardare la logica all'interno.

Il metodo che controlla se l'oggetto è in collisione con un altro oggetto potrebbe essere chiamato checkForCollision .

Il metodo che risolve le collisioni dell'oggetto con altri oggetti potrebbe essere chiamato resolveCollisions o handleCollisions .

Quando due funzioni fanno quasi la stessa cosa è spesso il miglior tempo per dare loro nomi più specifici per rendere chiara la loro differenza.

score 3 · Answer 2

Direi che non c'è niente di sbagliato in questo. L'overloading del metodo è una pratica abbastanza comune, per molteplici ragioni. Se si ha la stessa esatta funzionalità, solo per due serie diverse di parametri, quindi usare lo stesso nome esatto ha perfettamente senso, e aiuta anche a chiarire che l'elenco dei parametri dovrebbe essere approssimativamente l'unica vera differenza tra le due funzioni. Semplifica davvero il codice nelle lingue che lo supportano.

Poiché avere queste due funzioni fa due cose leggermente diverse (A.collision () è più generale di B._collision ()), in questo caso, va bene per due ragioni:

Non sono davvero sovraccarichi. "collisione" < > "_collision" (a meno che Python non faccia qualcosa di cui non sono a conoscenza).
Non sono davvero sovraccarichi. classe A < > classe B. Anche se avessero lo stesso nome di base, gli altri programmatori dovrebbero essere in grado di distinguere tra le funzioni in due classi diverse abbastanza facilmente (a meno che non si sia sottoclassi di altre). Ovviamente, classi diverse tendono a fare le cose in modo diverso.

score 3 · Answer 3

In parole semplici:

I nomi dei metodi dovrebbero essere i verbi , quindi entrambi i nomi sono inadeguati.
Quando dai loro nomi appropriati (con un verbo), è improbabile che i nomi dei due metodi coincidano.
Anche se i due metodi hanno lo stesso nome, sono in classi diverse e non c'è modo di confonderli perché hanno spazi dei nomi diversi.
Non esistono regole di stile (o di altro genere) che affermino che due classi o interfacce distinte non possono avere metodi con lo stesso nome, anche se hanno la stessa firma (elenco parametri).

Ad esempio

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

Risposta breve: non c'è niente di sbagliato in questo.