Dipendenza delle dipendenze e firme dei metodi

1

Ho usato YADIF (ancora un altro framework per le dipendenze) in un'app PHP / Zend a cui sto lavorando per gestire le dipendenze. Ciò ha portato notevoli benefici in termini di classi di test e disaccoppiamento.

Tuttavia, una cosa che mi colpisce è che, nonostante il gioco di prestigio eseguito con questa tecnica, i nomi dei metodi impartiscono un grado di accoppiamento.

Probabilmente non è il miglior esempio -ma questi metodi sono distinti da ... diciamo il PEAR Mailer. I nomi dei metodi stessi sono una (sottile) forma di accoppiamento

//example
public function __construct($dic){
    $this->dic = $dic;
}

public function example(){
    //this line in itself indicates the YADIF origin of the DIC
    $Mail= $dic->getComponent('mail');        
    $Mail->setBodyText($body);
    $Mail->setFrom($from);        
    $Mail->setSubject($subject);
}

Potrei scrivere una serie di proxy / wrapper per nascondere questi metodi e quindi promuovere il disaccoppiamento, ma questo sembra un po 'eccessivo. Devi bilanciare la purezza con il pragmatismo ...

Quanto lontano faresti per nascondere le dipendenze nelle tue classi?

    
posta sunwukung 27.04.2011 - 20:19
fonte

3 risposte

2

Devi abbinarti ad altre interfacce. Se si introducono wrapper, si sta semplicemente accoppiando a un'altra interfaccia e questo è inutile. Cosa vuoi evitare:

  1. Avere un dato pezzo di codice accoppiato a troppe interfacce
  2. Accoppiamento di un pezzo di codice a un'implementazione particolare.

Prendi l'esempio particolare di una classe mailer. Ottieni un riferimento alla classe mailer. Chiami i metodi che comportano l'invio di un'e-mail. Ma non sai come viene inviata l'e-mail. Sei preoccupato per il fatto che, in sostanza, possiamo dire che stai inviando una e-mail. Questo è il punto.

In un'altra nota, quello che stai facendo in questo esempio non è l'iniezione di dipendenza. Si sta utilizzando il framework di iniezione delle dipendenze per implementare un localizzatore di servizi. Nel modello di localizzazione del servizio, si richiede ciò che si desidera da un oggetto particolare ($ this- > dic) in questo caso. In Injection dipendenza i componenti necessari sono dati all'oggetto (spesso nel costruttore) e non ha idea da dove provengano.

    
risposta data 27.04.2011 - 21:45
fonte
2

Sì, potresti scrivere milioni di proxy / wrapper / what-have-you (e devi farlo a te stesso per iniziare a farlo immediatamente), ma tutti voi dovete nominarli. Tuttavia, in nome della purezza, ogni sforzo concepibile e inconcepibile non è solo giustificato ma obbligatorio.

Ci sono ancora più sottili livelli di accoppiamento. Ad esempio l'accoppiamento con il senso comune. Come hai intenzione di rimuovere quello?

    
risposta data 28.04.2011 - 15:16
fonte
1

Questo non sarebbe il migliore in termini di eliminazione delle dipendenze, ma potresti imporre un'interfaccia. In questo modo, la tua dipendenza dovrà implementare alcuni metodi obbligatori.

Se usi una libreria / framework di terze parti, creo quindi un adattatore che implementa la stessa interfaccia.

In pseudo-codice:

thirdPartyClassObj = new Third_Party_Class();

adapterObj = new myAdapter(thirdPartyClassObj);

myClass(adapterObj);

Nel codice myClass puoi verificare se sono stati implementati i giusti metodi

public function __construct($obj){
    if ($this->_isObjValid($obj) {
        $this->dic = $dic;
    } else {
        // throw an exception
    }
}

private function _isObjValid($obj) {
    if (!method_exists($obj, 'a') {
        return false;
    }
    if (!method_exists($obj, 'b') {
        return false;
    }
    return true;
}
    
risposta data 27.04.2011 - 21:32
fonte

Leggi altre domande sui tag