La classe DBQuery può essere unita o estendere la classe DBConnection?

6

Questa è una domanda sulle relazioni di classe e non sulle funzionalità di classe.

Attualmente le mie classi DBConnection e DBQuery sono due oggetti separati

class DBConnection {
    public $dbh;

    __construct() {
       $this->dbh = ... //Establish Connection to db
    }
}

class DBQuery {
    private $dbh;

    __construct(PDO $dbh) {
       $this->dbh= $dbh;
    }

    public runSQLQuery($query) {
       $result = $this->dbh->execute($query);
       $return $result;
    }

}

$dbh = new DBConnection();
$DBQuery = new DBQuery($dbh);
$DBQuery->executeSQLQuery("SELECT * FROM mytable");

Così ho iniettato DBConnection in DBQuery .

Prima domanda - posso averli uniti come un unico oggetto invece che $dbh è improbabile che possa essere usato in qualsiasi altra classe rispetto a DBQuery . È questa cattiva pratica raggrupparli, perché?

class DBQuery {
    private $dbh;

    __construct() {
       $this->dbh = ... //Establish Connection to db
    }


    public runSQLQuery($query) {
       $result = $this->dbh->execute($query);
       $return $result;
    }

}


$DBQuery = new DBQuery();
$DBQuery->executeSQLQuery("SELECT * FROM mytable");

Seconda domanda - Se la fusione è No-No allora, che ne dici di estendere, mantiene DBConnection class separata in modo che possa essere usata da un'altra classe, se necessario, la classe DBQuery semplicemente estende la classe %codice%. Sembrano essere correlati logicamente quindi anche questa cattiva pratica, perché?

class DBConnection {
    public $dbh;

    __construct() {
       $this->dbh = ... //Establish Connection to db
    }
}

class DBQuery extends DBConnection {

    __construct() {
       parent::__construct()
    }

    public runSQLQuery($query) {
       $result = $this->dbh->execute($query);
       $return $result;
    }

}

$DBQuery = new DBQuery();
$DBQuery->executeSQLQuery("SELECT * FROM mytable");

La linea di fondo è che sto cercando di trovare una soluzione in cui non devo istanziare oggetti extra (usa troppe righe di codice) e scrivere righe di codice non necessarie all'interno delle classi solo per passare l'una all'altra per nessun ovvio ragionare.

P.S. Ho familiarità con SOLID OOD e Separation of Concerns tuttavia non vedo ancora previsioni per tenere separate queste due classi.

    
posta Bananas 22.11.2016 - 21:27
fonte

1 risposta

1

La decisione (corretta) di separare queste due classi ha più a che fare con il Principio della singola responsabilità:

Wikipedia :

The single responsibility principle states that every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility. Robert C. Martin expresses the principle as follows:

"A class should have only one reason to change."

Enfasi, mia.

Se il modo in cui si stabilisce una connessione al database cambia, come dovrebbe influire sull'esecuzione di un comando?

Se il modo in cui un comando viene eseguito su una connessione già stabilita, come dovrebbe influire sul modo in cui viene aperta una connessione?

La separazione dei due ti consente di ridefinire il modo in cui le connessioni vengono gestite senza impatto sul codice già in uso per l'esecuzione di query e viceversa.

Come appendice, la tua classe DbQuery dovrebbe davvero richiedere un oggetto DBConnection nel suo costruttore. Ciò consente un accoppiamento più lento tra le due classi, poiché l'oggetto query non deve sapere come ottenere e aprire una connessione. Qualcos'altro lo fa per questo.

    
risposta data 22.11.2016 - 23:00
fonte

Leggi altre domande sui tag