Devo smettere di usare Dependency Injection per mantenere piccole le stampe di debug degli oggetti?

Question

Devo smettere di usare Dependency Injection per mantenere piccole le stampe di debug degli oggetti?

#1 da (6 voti)

4

Supponiamo di avere un oggetto di grandi dimensioni - pensa EntityManager di un ORM come Doctrine o un oggetto DAO personalizzato o cosa hai. Oggetto, il cui output è richiesto per essere utilizzato all'interno di una classe, ma l'oggetto stesso potrebbe essere transitorio - svolgere il proprio lavoro e quindi uscire dall'ambito.

Non sempre importa se tale oggetto è grande o no, ma non è necessario far parte della classe. Tuttavia il suo sottoprodotto è. Esempio:

//i.e. Doctrine\ORM\EntityManager
class BigTerribleDatabaseObject
{
    //300 methods and 20 properties
}

Quando non si utilizza DI

BigTerribleDatabaseObject è usato solo per ottenere alcuni dati e poi viene scartato.

class Small
{
    public getData($id)
    {
        $db = new BigTerribleDatabaseObject();
        return $db->getDataById($id);
    }
}

Utilizzo DI

BigTerribleDatabaseObject diventa un residente permanente della piccola classe, nonostante sia stato iniettato (viene iniettato e quindi rimane).

class Small
{
    private $db;
    function __construct(BigTerribleDatabaseObject $db)
    {
        $this->db = $db;
    }

    public getData($id)
    {
        $db = $this->db;
        return $db->getDataById($id);
    }
}

Il mio problema

A volte faccio un'istruzione print_r a scopo di debug su un oggetto. Mi piace così:

//first line depending on whether or not I use DI or not:
$myClass = new Small(new BigTerribleDatabaseObject())
$myClass = new Small()

print_r($myClass);

Con DI $myClass stampa il contenuto di Small E anche tutto il contenuto di BigTerribleDatabaseObject , perché BigTerribleDatabaseObject fa parte di Small .

Questo inonda il mio schermo e talvolta anche il mio browser si blocca perché nel mio caso è il gestore di entità di Doctrine ed è enorme e poco maneggevole.

Senza DI ottengo una bella stampa solo della mia classe molto piccola. Quale penso sia più pulito.

Quindi devo scegliere tra "nice e small print di debug senza DI" o "use DI, ma subiscono stampe di debug ampie e ingombranti".

Domanda

Preferisco di gran lunga la stampa più piccola. Significa che devo scartare usando le tecniche di Iniezione di Dipendenza? Posso usare qualcos'altro? È un male necessario per il DIing di grandi oggetti transitori?

object-oriented dependency-injection php

posta Dennis 01.03.2016 - 21:05

fonte

1 risposta

Leggi altre domande sui tag object-oriented dependency-injection php

I Web Form ASP.Net producono effettivamente un codice HTML compatibile con ADA? Il toolkit ASP / AJAX compromette l'obiettivo della conformità ADA? In Scheme, qual è lo stato formalmente di un programma?

score 6 · Accepted Answer

Si noti che nell'esempio corrente, non vi è molto vantaggio dal passare l'oggetto dal chiamante, poiché Small non viene disaccoppiato dal database. Quindi non dovresti smettere di usare DI - al contrario, dovresti iniziare a usarlo correttamente.

Invece di iniettare l'oggetto della classe BigTerribleDatabaseObject , è possibile iniettare un metodo factory per quel tipo di oggetti in Small per evitare la necessità di chiamare direttamente il costruttore. O meglio, la fabbrica potrebbe incapsulare direttamente l'operazione di lettura del database per dare al tuo SmallFootprintInnocentClass la possibilità di essere testato con una fabbrica "finta", senza accesso al vero database. Qualcosa sulla falsariga di

class Small
{
    private $myDataFactory;
    function __construct(function $myFactory)
    {
        $this->$myDataFactory = $myFactory;
    }

    public getData($id)
    {
        return $myDataFactory($id);
    }
}

(perdonami se ho sbagliato la sintassi, non sono un programmatore PHP fluente).

Poiché la factory probabilmente non ha uno stato interno minimo o minimo, print_r comporterà una stampa minima.