PHP: definieer constanten buiten een klasse of in de constructor?

ik ben nieuw in klassen en oo. Ik was in eerste instantie op zoek naar een eenvoudige MySQL-klasse en ik vond "A Simple MySQL Class" van Matthew Saragusa.

Dit zijn de eerste regels:

define('SIMPLE_DB_SERVER', 'mysqlserver.net');
define('SIMPLE_DB_NAME', 'mydbname');
define('SIMPLE_DB_USERNAME', 'myusername');
define('SIMPLE_DB_PASSWORD', 'mypassword');
class ASimpleMySQLDB {
    public function __construct($server, $database, $username, $password){

        $this->conn = mysql_connect($server, $username, $password);
        $this->db = mysql_select_db($database,$this->conn);
    }
[...]

Ik vraag me af of er een specifieke reden is waarom constanten buiten de klasse worden gedefinieerd, in plaats van de constructor te gebruiken - bijvoorbeeld:

public function __construct(){
    $this->conn = mysql_connect('localhost', 'username', 'password');
    $this->db = mysql_select_db('database',$this->conn);
}

Of:

public function __construct($which_db){
        if($which_db=='firstdb'){
            $server='localhost';
            $username='user1';
            $password='pass1';
            $database='db1';
        }elseif($which_db=='otherdb'){
            $server='localhost';
            $username='user2';
            $password='pass2';
            $database='db2';
        }

    $this->conn = mysql_connect($server, $username, $password);
    $this->db = mysql_select_db($database,$this->conn);

}

Of met behulp van een schakelaar of wat dan ook.

Wat is het verschil tussen de twee methoden? Welke zou je aanbevelen? Hartelijk bedankt :-)

4
Hoe zit het met het definiëren van hen in een .ini-bestand: P
toegevoegd de auteur Esailija, de bron
Wat is beter leesbaar?
toegevoegd de auteur Platinum Azure, de bron

5 antwoord

Hoewel het tegenwoordig grotendeels wordt ontmoedigd door de meeste OO PHP-ontwikkelaars, gebruiken veel bibliotheken nog steeds define() om configuratieconstanten in te stellen die moeten worden aangepast door de eindpartij die de bibliotheek implementeert. Deze worden meestal weggestopt in een configuratiebestand dat vereist/opgenomen is door de klasse die deze configuratie-informatie nodig heeft, of is opgenomen nog verder een back-up van de stapel als deze globaal nodig is (Wordpress voor de geest).

PHP 5 bevat klasseconstanten om aan dezelfde functie te voldoen, maar alleen in het bereik van de klasse zelf.

http://php.net/manual/en/language.oop5.constants.php

Deze aanpak is een goede manier om klassespecifieke, onveranderlijke waarden te creëren die uw bibliotheek nodig heeft. Aangezien een van de primaire doelen van het gebruik van OOP in PHP de hergebruikbaarheid van code is, wordt de configuratie mooi verpakt voor release. In het geval van uw databaseklasse kunt u const -verklaringen hebben voordat uw construct-methode alle toegangsreferenties definieert, zoals de db_host, db_user en db_pass. Houd er rekening mee dat deze constanten moeten worden geopend door ClassName :: ConstName zoals een statische methode zou doen.

Hoewel OOP in PHP een lange weg heeft afgelegd en nu wijdverbreid is, gebruiken een heleboel oudere of meer "ingesloten" frameworks en bibliotheken nog steeds de definitieconventie, dus je zult het heel vaak gebruikt zien worden, zelfs in OO-omgevingen.

3
toegevoegd
Als je ook gewoon aan het leren bent, stel ik voor om zoveel mogelijk te lezen van het klassenhoofdstuk van de PHP-documentatie. Het helpt echt bij het begrijpen van kernzaken zoals statische versus instantiale methoden en objectovername. php.net/manual/en/language.oop5.php Even sinds lang de overstap naar Python gemaakt heb vanuit PHP in mijn team, de kwaliteit en de reikwijdte van PHP's documentatie is nog steeds iets dat ik echt mis!
toegevoegd de auteur DeaconDesperado, de bron
Heel erg bedankt, precies wat ik hoopte te horen.
toegevoegd de auteur Giona, de bron
Ik leerde PHP autodidactisch, nu lees ik een boek van Peter MacIntyre shop.oreilly.com/product/9780596804381.do Helaas ben ik Italiaans, hoewel ik bekend ben met Engels, technische taal is nog steeds moeilijk voor mij :-)
toegevoegd de auteur Giona, de bron
  1. Andere bestanden/klassen hebben dus toegang tot de gedefinieerde waarde (GLOBAL)
  2. Gemakkelijker te bewerken voor het geval u in de toekomst uw db gaat wijzigen

De beste manier om dit te implementeren, is om een ​​configuratiebestand te maken met al deze definities. d.w.z

configuration.php

define('SIMPLE_DB_SERVER', 'mysqlserver.net');
define('SIMPLE_DB_NAME', 'mydbname');
define('SIMPLE_DB_USERNAME', 'myusername');
define('SIMPLE_DB_PASSWORD', 'mypassword');

en neem ze op in uw MySQL-verbindingsklasse connection.php

include "configuration.php";

class DBConnection 
{
    public function __construct(){
        $this->conn = mysql_connect(SIMPLE_DB_SERVER, SIMPLE_DB_USERNAME, SIMPLE_DB_PASSWORD);
        $this->db = mysql_select_db(SIMPLE_DB_NAME,$this->conn);
    }
}
3
toegevoegd

Ik ben niet zeker van de specifieke context van die specifieke MySQL-verbindingsklasse, maar het verschil tussen het definiëren van de verbindingsinformatie als constanten in plaats van klasseneigenschappen is een bereik.

De constanten zijn overal in de codebase beschikbaar nadat die regel code is uitgevoerd, zodat u ze buiten de klasse ASimpleMySQLDB kunt openen. Alle variabelen gedefinieerd binnen de constructor, aan de andere kant, zouden niet werken buiten de klas.

Vaak zie ik dat mensen constanten aan het begin van hun code gebruiken om waarden in te stellen die door de eindgebruiker (meestal slechts eenmaal) moeten worden aangepast (WordPress gebruikt dit in hun wp-config.php-bestand http://codex.wordpress.org/Editing_wp-config.php ). Op deze manier hoeven mensen niet in de klasse zelf te graven om te vinden waar de DB-verbindingswaarden moeten worden ingesteld. Ik vermoed dat deze leesbaarheidsfactor de reden is waarom deze auteur heeft besloten om constanten te gebruiken.

1
toegevoegd
Heel erg bedankt voor je reactie! Er is dus geen andere reden dan om ze buiten de klas beschikbaar te stellen? Omdat ze niet door andere delen van de code worden gebruikt (daarom wil ik dat een klasse databaseverbindingen beheert), zou ik ze in de constructor plaatsen. nogmaals bedankt
toegevoegd de auteur Giona, de bron
JEP. Gaandeweg met wat DeaconDesperado zei, het is meestal een conventie op dit punt, en dit betekent dat je MySQL-verbindingsinformatie beschikbaar is in de codebase buiten de verbindingsklasse, wat de veiligheid niet bevordert.
toegevoegd de auteur brandwaffle, de bron

Deze scheiding komt hoogstwaarschijnlijk omdat de klasse ASimpleMySQLDb een wrapper is rond een database. Dit is een algemene klasse, dus om het specifiek te maken door hard coding verbindingsdetails in de constructor zou het zo maken dat je het niet opnieuw zou kunnen gebruiken. U wilt die flexibiliteit behouden, zelfs binnen één enkele applicatie, omdat u mogelijk meerdere databases zult gebruiken.

Persoonlijk maak ik meestal een toepassing -klasse die het singleton-patroon volgt en verklaar mijn databaseverbindingsdetails als statische -variabelen binnen die klasse. Hierdoor kan ik nog steeds gemakkelijk mijn databaseverbindingsinformatie wijzigen of extra databases toevoegen als dat nodig is.

0
toegevoegd

Constanten gedefinieerde en op één plaats. En in uw voorbeelden zouden andere ontwikkelaars moeten zoeken waar de databaseparameters zijn.

0
toegevoegd