come suddividere una classe delegata

Question

come suddividere una classe delegata

#1 da (1 voti)

2

Ho una classe di comunicazione che incapsula tutte le API di un'applicazione remota. Questa classe sembra essere una classe delegata perché è intercambiabile con un'altra (l'applicazione remota ha due canali diversi).

Questa classe ha una serie di argomenti (ad esempio: riconoscimento, persone, fatture, duedati, metodi di pagamento, code) e ogni argomento ha un numero di metodi (setOne, getOne, getAll, doSomething ...). Il numero di argomenti sta aumentando rapidamente di recente, da 1 a 6 e forse anche in futuro.

Considerando che la classe stessa ha bisogno di alcuni metodi di scaffolding (configurazione, avvio, autenticazione ...) e ogni argomento ha bisogno di un metodo protetto ausiliario, il numero totale proiettato di metodo va oltre la mia zona di confort.

Se questa classe non fosse di per sé una classe delegata, avrei implementato questa soluzione: una classe per ogni argomento, ognuno facendo uso della classe comune e, se necessario, degli altri. Ma il codice cliente vuole essere dato solo una classe a cui effettuare richieste.

Un'opzione consiste nel creare una singola classe delegato con molti metodi relay per gli oggetti compositi. Ma non credo che questo sia molto lontano dall'ingestare la rana e solo avere una grande classe piena di cose.

Ci sono altre soluzioni?

Sto lavorando su php e uso il metodo meta

delegates

posta Vittorio Zamparella 30.10.2015 - 00:44

fonte

1 risposta

Leggi altre domande sui tag delegates

Lottando sui vantaggi dell'uso di un approccio plugin in un'architettura software industriale [chiuso] Come fa il runtime Python a sapere a quale oggetto è associato un metodo?

score 1 · Answer 1

È necessario scrivere metodi in tre dimensioni, per così dire: canale, argomento e operazione. Una volta ho risolto un problema simile combinando i comandi di [1] con le fabbriche (astratte) [2].

L'idea di base è scrivere una Classe di Comando per ogni combinazione di (canale, argomento, operazione) che hanno tutti un'interfaccia comune. Nel tuo caso qualcosa come

Response sendRequest()

sembra ragionevole.

Inoltre, ogni oggetto comando ha bisogno di tutte le risorse prontamente disponibili come membro per eseguire il proprio compito. I dettagli dell'acquisizione di tali risorse e dell'impostazione di un comando specifico con esso sono incapsulati nelle corrispondenti fabbriche. Con le gerarchie di tipo intelligenti dei comandi e delle fabbriche effettive è possibile separare il codice comune da quello specializzato.

Fammi fare un po 'di bozza e cerca di chiarire cosa intendo:
Supponiamo che tu voglia elencare tutte le persone (operazione) (argomento) con cognome "Jackson" (operazione) come una richiesta XML (canale), il codice cliente sarebbe simile a questo:

$xmlCommandFactory = CommandFactories.createFactory('XML'); // returns specific factory for channel; Specific factories share same interface
$peopleCommandFactory = xmlCommandFactory->createPeopleFactory(); // returns specialieced factory for topic
$command = peopleCommandFactory->createListByLastName('Jackson'); // creates specific command with specific parameter
$response = command.sendRequest(); // executes command

Questo rende molto astrazione e codice piastra caldaia. Tuttavia, la bellezza dei livelli multipli è che ogni livello ha a che fare con una sola dimensione. Ad esempio, se volessi la stessa cosa di Json-Request, il codice sarebbe simile a questo:

$xmlCommandFactory = CommandFactories.createFactory('JSON'); // returns specific factory for channel; Specific factories share same interface
$peopleCommandFactory = xmlCommandFactory->createPeopleFactory(); // returns specialieced factory for topic
$command = peopleCommandFactory->createListByLastName('Jackson'); // creates specific command with specific parameter
$response = command.sendRequest(); // executes command

Questo vale anche per l'effettiva implementazione. createFactory ($ type) , ad esempio, si occupa solo della decisione di quale factory istanziare per il canale richiesto.
Un altro vantaggio è la scalabilità. Semplicemente aggiungi nuove, piccole classi di comando, invece di mantenere un unico pezzo di codice monolitico. Ciò dovrebbe essere d'aiuto anche quando si scrivono dei test, dato che frammenti più piccoli di codice incapsulato sono intrinsecamente più facili da testare.
Ultimo ma non meno importante, è possibile disaccoppiare il processo decisionale (cosa ottenere come e con quali parametri) dall'esecuzione effettiva, passando i comandi e / o le fabbriche in giro. Questo potrebbe rivelarsi utile o no.

[1] link
[2] link