Un metodo con molti comportamenti o molti metodi

Question

Un metodo con molti comportamenti o molti metodi

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

0

Questa domanda è abbastanza generale e non correlata a una lingua specifica, ma più alla codifica delle best practice.

Recentemente, ho sviluppato una funzione per la mia app che è richiesta in molti casi con comportamenti leggermente diversi.

Questa funzione invia e-mail, ma a destinatari diversi o con testi diversi in base ai parametri. La firma del metodo è qualcosa come

public static sendMail (t_message message = null  , t_user receiver = null , stream attachedPiece = null)

E poi ci sono molte condizioni all'interno del metodo, come

if(attachedPiece != null)
{
}

Ho fatto la scelta di farlo in questo modo (con un solo metodo) perché mi impedisce di riscrivere il (quasi) stesso metodo 10 volte, ma non sono sicuro che sia una buona pratica.

Che cosa avrei dovuto fare? Scrivi il 10% disendMail metodo con parametri diversi?

Ci sono evidenti vantaggi e svantaggi per questi diversi modi di programmazione?

Grazie mille.

programming-practices patterns-and-practices

posta Krowar 26.05.2014 - 15:23

fonte

3 risposte

Leggi altre domande sui tag programming-practices patterns-and-practices

Esiste un modello di progettazione per applicare dinamicamente trasformazioni o filtri a un modello? Memorizzazione nella cache dell'immagine durante il rendering delle stesse immagini su pagine diverse [chiuso]

score 3 · Answer 1

l'allegato raramente manca? Se così fai come hai fatto. Se è raramente presente, crea un metodo senza il parametro attachment che chiama questo metodo. Non c'è bisogno di ricodificare tutto una dozzina di volte.

Dì con 3 parametri, 1 dei quali sono quasi sempre lì, il terzo raramente, potresti ottenere qualcosa come:

method1(param1, param2, param3) {
  // full implementation
}

method1(param1, param2) {
  method1(param1, param2, null);
}

score 2 · Answer 2

C'è uno svantaggio di avere tutte le permutazioni sui parametri nello stesso metodo, poiché si finirà con una complessità ciclomatica alta , cioè ci sono molti percorsi per attraversare la tua logica, e questo è difficile da testare e ragionare. Ogni volta che aggiungi un parametro nullo, aumenti questa complessità di un fattore 2 e si consiglia di non superare i 10 , tranne per le situazioni rare.

La soluzione più semplice per evitare la complessità ciclomatica è il refactoring in metodi più piccoli. Fammi usare Python come pseudocodice per questo semplice esempio:

class MyApp():
    def send_mail(message=None, receiver=None, attachedPiece=None):
        if message:
            # ... do something ...
        if receiver:
            # ... do another thing ...
        if attachedPiece:
            # ... attach to message ...

dovrebbe essere riscritto in:

class MyApp():
    def send_mail(message=None, receiver=None, attachedPiece=None):
        process_body(message, receiver)
        attach_piece(attachedPiece)
    def process_body(message, receiver):
        if message:
            # ... do something ...
        if receiver:
            # ... do another thing ...
    def attach_piece(attachedPiece):
        if attachedPiece:
            # ... attach to message ...

Ora invece di un singolo metodo con complessità 8, hai due metodi di complessità 4 e 2. Questo non si ripete, poiché il codice non è condiviso tra i metodi refactored. Ho raggruppato due dei condizionali nel metodo originale send_mail in un singolo metodo refactored per mostrare che questo tipo di refactoring non porta necessariamente a un piccolo metodo per ciascuno dei parametri originali.

score 1 · Answer 3

Sì, è una buona pratica , ma se non ti senti a tuo agio con esso potresti voler considera un'interfaccia fluente . In questo modo, sarai in grado di mettere i diversi comportamenti in diversi metodi, ma invece di scrivere un metodo per ciascuna combinazione di argomenti devi solo scrivere un metodo per ogni argomento.