Re-design correttamente da Passa a Polymorphism (principio Apri / Chiudi)

I tuoi repository dovrebbero essere derivati da una classe base comune, chiamiamola baseRepository . Questa classe deve fornire due metodi virtuali

• correspondingNamespace()

• processReponse(responseKey)

Oltre i metodi nelle classi derivate, quindi correspondingNamespace dovrebbe restituire lo spazio dei nomi corretto per ciascun repository, ad esempio "client" per customerRepository . processReponse dovrebbe delegare alla singola logica aziendale come chiamare doSomething o chiamare doSomethingTotallyDifferent con parametri diversi.

Ora puoi facilmente inizializzare un dizionario con i repository disponibili in anticipo, in pseudo codice:

for each repo in [customerRepository, invoiceRepository]:
     repoDict[repo.correspondingNamespace()]=repo

E l'elaborazione della risposta sembrerà (approssimativamente) come:

  repoDict[responseKey.namespace].processReponse(responseKey)

Al tuo commento: se non vuoi aggiungere direttamente questi metodi ai repository, puoi usare una gerarchia separata di classi di strategia e posizionare lì i due metodi. Ricava customerResponseStrategy e invoiceResponseStrategy da responseStrategy , e lascia che ogni responseStrategy tenga un riferimento al repository corrispondente. Ciò porterà a qualcosa di simile

 for each respStrat in 
        [new customerResponseStrategy(customerRepository),
         new invoiceResponseStrategy(invoiceRepository)]:
         responseStrategyDict[respStrat .correspondingNamespace()]=respStrat 

e

  responseStrategyDict[responseKey.namespace].processReponse(responseKey)

Ciò che ho fatto molte volte nei progetti e che ha aiutato un sacco con nuove richieste di funzionalità è stato:

interface JobResponseWorker {
    bool canProcess(namespace);
    void process(response);
}

class ClientResponseWorker implements JobResponseWorker {

    bool canProcess(namespace) {
        return namespace == "client"
    }
    void process(response) {
        //... whatever you want to do here
    }
}

class InvoiceResponseWorker implements JobResponseWorker {
    bool canProcess(namespace) {
        return namespace == "invoice"
    }
    void process(response) {
        //... whatever you want to do here
    }
}

workers = [new ClientResponseWorker(), new InvoiceResponseWorker()]

//your main logic
void processResponse(namespace, request, response) {

    for (JobResponseWorker worker in workers) {
        if (worker.canProcess(namespace)){
            worker.process(response)
        }
    }
}

In questo modo, la maggior parte del tuo codice principale è chiuso per le modifiche. Per i nuovi lavoratori, aggiungi un nuovo codice (aperto per l'estensione), quindi aggiungi solo un altro oggetto in un array (nessuna logica aggiuntiva nel vecchio codice).

Penso che quello che stai cercando qui è il tipo di approccio descritto dal modello Strategia . In poche parole, devi tradurre i tuoi spazi dei nomi in classi / oggetti. Nel tuo esempio avresti una classe Client e una classe Invoice . Ciascuno avrebbe un metodo doTheThing() .

Ciò che rimane è che è necessario disporre di una sorta di interruttore o mappa che determina il tipo da utilizzare. Questo potrebbe sembrare un po 'inutile in un semplice esempio come questo, ma con l'aumentare del numero di operazioni e classi, semplificherebbe notevolmente sia il codice che renderlo molto più comprensibile. Sarai anche più in grado di aggiungere nuovi tipi senza toccare la logica esistente per altri tipi.

Se hai solo un posto nel codice in cui devi fare questa discriminazione, dovresti stare con esso. Ma se hai più punti in cui è necessario applicare un comportamento diverso sul valore namespace , dovresti optare per l'approccio "polimorfico".

Il problema è che con un approccio "polimorfico" devi fare anche la discriminazione perché devi selezionare l'implementazione che appartiene al tuo valore namespace ad un certo punto.