Per i programmi small-ish, un singolo metodo dovrebbe gestire la maggior parte delle chiamate di metodo per centralizzare il flusso del programma?

Question

Per i programmi small-ish, un singolo metodo dovrebbe gestire la maggior parte delle chiamate di metodo per centralizzare il flusso del programma?

#1 da (4 voti)

1

Sono abbastanza nuovo per OOP (e programmazione in generale), ma quello che mi trovo a fare è che nel caso in cui non avessi bisogno di passare un valore da un metodo a un altro, avrò il mio metodo chiama centralizzato in alcune classi all'interno di un file Form.cs.

Ad esempio:

public void CentralMethod()
{
    MethodA();
    MethodC();
    MethodD();
}

MethodA () quindi eseguirà alcune cose e chiamerà MethodB () direttamente, a cui passa un valore. Tuttavia, dopo che MethodB () è terminato, il controllo ritorna a CentralMethod () e poi MethodC () viene chiamato, ecc.

Riesco a vedere come si tratti di un incubo su un grande progetto, ma è un'abitudine che si dovrebbe affrontare in un progetto relativamente piccolo? Non l'ho fatto necessariamente in base alla progettazione, ma mi sono trovato a farlo quando non era logico includere alcune chiamate di metodo all'interno di altri metodi.

c# methodology

posta Ryan 10.01.2013 - 23:24

fonte

1 risposta

Leggi altre domande sui tag c# methodology

Come funziona una competizione come Rails Rumble? Flash scompare? [chiuso]

score 4 · Answer 1

Hai detto che la tua logica per chiamare i metodi in questo modo è quando i metodi non passano i parametri da uno all'altro. Cosa intendi esattamente con questo?

Se si intende che i metodi non sono direttamente correlati a un singolo processo (ad esempio, un metodo PerformMaintenance() che chiama CleanCache() e quindi CheckForDeadOrders() ), allora questo ha senso. Questo è un singolo metodo principale che ha diverse sezioni, eseguite indipendentemente, ma che fanno parte della stessa unità logica di lavoro.

Tuttavia, se per "non passare parametri" si intende "usa variabili membro condivise", potrebbe essere un problema. Se hai qualcosa di simile:

private List<Order> _orders;
public Order FindMatchingOrder()
{
    LoadOrders();
    SortOrders();
    return _orders.First();
}

dove i metodi condividono i dati, ma ognuno modifica semplicemente la variabile _orders , quindi sì, direi che questa è una cattiva pratica. È una cattiva pratica perché salva lo stato persistente senza motivo, il che rende il codice meno thread-safe e probabilmente incline ad altri bug. È una cattiva pratica perché il flusso di dati tra i metodi non è chiaro, dal momento che non è implicito nel loro contratto: un LoadOrders() che ha restituito un elenco di ordini che viene poi passato a SortOrders sarebbe più esplicito.