Een variabele definieert een waarde, maar kan een verwijzing zijn naar een andere variabele en zijn waarde hebben. Tijdens de uitvoering van een algoritme neemt een variabele doorgaans veel verschillende waarden aan. Een constante slaat slechts één waarde op. Een object is onvoorspelbaar: het heeft meestal structuur, inhoud en veel kenmerken.

Een naamruimte is een verzameling variabelen, constanten, objecten, functies en andere constructies die door de ontwikkelaar zijn gemaakt en waarnaar kan worden verwezen via de naam van deze naamruimte.

Namen: het gebied van beschrijving van gegevens en algoritmen

De namen van elementen (variabelen, constanten, objecten, functies en andere ontwikkelaarsconstructies) kruisen elkaar nooit. PHP interpreteert elke naammatch als een ernstige fout, en in gevallen waarin het probleem niet duidelijk kan worden geïdentificeerd, ontvangt de ontwikkelaar code die niet werkt zoals bedoeld, of een wit vakje in de browser.

Alle namen van alle gegevens moeten uniek zijn omdat de ruimte globaal is. De namen van objecten en functies mogen ook niet worden herhaald, maar de reikwijdte van de globale zichtbaarheid wordt onderbroken in de methodelichamen van objecten en functies. Het heeft zijn eigen lokale naamruimte en niets belet je om iets intern op dezelfde manier een naam te geven als extern.

Het bovenstaande voorbeeld is een klassieker, als je geen aandacht besteedt aan het zoekwoord naamruimte: alles is zoals altijd. De tweede omvat werken. Het NameSpaceTwo\-voorvoegsel vóór de functienamen geeft aan uit welke insert de code is gehaald.

Als we het globale trefwoord en de bewerking verwijderen uit de eerste functie $iExt = 1; ga naar de regel erboven, dan weet noch de eerste noch de tweede functie de waarde van de variabele 100.

Naamruimten: meerdere beschrijvingsbereiken

Het getoonde voorbeeld heeft een gedeeld bestand dat twee invoegingen gebruikt. Elke invoeging heeft dezelfde scCheckName()-functie. Welke hij moet kiezen, wordt door de programmeur bepaald door de naam van de ruimte te gebruiken die op het juiste moment op de juiste plaats in de code relevant is.

Het feit dat dezelfde naam aanwezig is in de gemeenschappelijke code (na het samenvoegen van inserts) veroorzaakt geen fout om de eenvoudige reden dat elk insert-bestand is gemarkeerd met zijn eigen unieke naam.

In het eerste bestand is alles wat erin wordt beschreven gekoppeld aan de naam NameSpaceOne. In het tweede bestand worden alle beschrijvingen gekoppeld aan de naam NameSpaceTwo.

Elke duplicatie van namen in beide bestanden is toegestaan, maar in elk van deze bestanden moet elke elementnaam (variabele, constante, object, functie) uniek zijn.

In dit voorbeeld voorkwam het wijzigen van de naamruimtenaam in de functieaanroep scCheckName() dat de variabele $iExt van de tweede naamruimte werd gewijzigd. Daarom is in het voorbeeld het woord “gewijzigd” speciaal benadrukt: de verandering heeft niet daadwerkelijk plaatsgevonden. De waarde van de variabele blijft hetzelfde.

Testen en meerdere ontwerpen

Deze eenvoudige voorbeelden laten zien dat u de ontwikkeling van complexe projecten eenvoudig kunt vereenvoudigen, de efficiëntie en productiviteit kunt verhogen en het werk kunt versnellen. Absoluut, de eerste ideeën voor het gebruik van naamruimten verschenen meteen:

• veilig testen van scripts - door “werk” ruimtes te vervangen door testanalogen;
• veilig ontwerp door grote teams van ontwikkelaars - door hen “individuele” ruimtes te bieden voor het beschrijven van elementen.

Naamruimte is eigenlijk veel belangrijker. De PHP-taal, naamruimte en elk element van de beschrijving (variabel, constant, object...) bieden de ontwikkelaar al lang de mogelijkheid om syntaxis en semantiek onafhankelijk te manipuleren.

Taalconstructies en de algemene regel van modern programmeren: “begrepen” – uitgevoerd – er is een tegenstrijdigheid – een “wit scherm” heeft “geen enkel effect” op een professionele ontwikkelaar.

Veel programmeurs weten niet eens waar ze moeten zoeken naar een PHP-foutmelding als er niets in de browser staat (een leeg wit vakje). In een bepaald stadium van zijn ontwikkeling denkt een programmeur in PHP-syntaxis en semantiek, “werkt” automatisch en het resultaat: zijn eigen syntaxis en zijn eigen semantiek, binnen de grenzen van wat is toegestaan.

Een wit scherm is een onmiddellijke, ondubbelzinnige reactie van een professionele programmeur en de fout is geëlimineerd. Waarom tijd verspillen aan een debugger en het bekijken van het foutenlogboek?

Objecten, arrays en naamruimten

Je zou kunnen zeggen dat variabelen, constanten en functies tot het verleden behoren, maar ze worden wel gebruikt bij het ontwerpen van objecten. Goede code is wanneer het algoritme wordt weergegeven door op elkaar inwerkende objecten, en niet door een reeks correcte constructies.

Als je arrays van objecten gebruikt, het idee van een stapel en het laatste (eerste) element van de array manipuleert, kun je dynamiek krijgen: de objecten zelf ‘beslissen’ hoe de functionaliteit van de site zou moeten werken, afhankelijk van de huidige situatie .

In PHP is een naamruimte een speciaal soort variabele, vertegenwoordigd door zijn eigen unieke naam, vaak complex. De naamruimtenaam wordt in de code gebruikt. Als dit een tekenreeks is, kunt u tijdens de uitvoering van het script de ene spatie door een andere vervangen.

Als PHP naamruimtenamen als variabelewaarden gebruikt, is dit een nog meer semantisch geladen syntaxis, zelfs sterker dan arrays van objecten.

Een object is een structuur en inhoud die gekenmerkt worden door eenheid. Een naamruimte is een verzameling objecten, elementen en relaties daartussen.

Het is niet mogelijk om experimenten uit te voeren op een draaiend systeem, maar dankzij de naamruimte biedt PHP de mogelijkheid om een ​​echt draaiend systeem in een andere ruimte te simuleren met als doel:

• verdere ontwikkeling;
• testen;
• onderhoud, enz.

Als we abstraheren van de door de PHP-ontwikkelaars voorgestelde syntaxis en naamruimten voorstellen als mondiale complexe systemen van objecten, breidt de horizon van mogelijkheden zich vele malen uit.

Syntaxis en gebruik van naamruimte

PHP accepteert alleen het woord naamruimte in de eerste regel code in elk bestand. Alle beschrijvingen mogen dit alleen volgen. De syntaxis omvat alleen de naam die in de gebruikelijke betekenis van de naam wordt aangegeven.

Het is belangrijk om de juiste woorden te gebruiken die de betekenis overbrengen. Het is beter als de naam lang is, maar iets bevat dat een duidelijk begrip geeft van over welke ruimte we het hebben, wat het doet, wat het beschrijft, wat het accepteert of waarvoor het is gemaakt.

Spaties kunnen voor onbepaalde tijd worden genest, maar dit mag niet te veel worden gebruikt. De naam moet duidelijk zijn, het nesten moet gerechtvaardigd zijn en de volgorde van de ruimtenamen moet logisch zijn.

In gebruiks- en naamruimtetoepassingen maakt PHP complexe codering mogelijk, maar waar mogelijk is het beter om genoegen te nemen met de eenvoudige optie.

De algemene regel is: naamruimte is een beschrijving en dit is één bestand, gebruik is het importeren van de ruimte in het gebruiksscript en het toewijzen van een alias (korte link) eraan.

Een eenvoudig voorbeeld van het automatisch laden van klassen (objecten)

De taak bevat een object voor het manipuleren van tekenreeksen, pagina-elementstijlen (CSS-beschrijvingen), een datumobject, een bestandssysteemobject en een databaseobject. Het punt van implementatie is het creëren van eenvoudige interfaces voor deze vijf posities, zodat de noodzakelijke mogelijkheden alleen via de methoden van deze objecten kunnen worden gebruikt.

Er is geen direct gebruik van taalfuncties en -constructies toegestaan. Deze taak maakt gebruik van automatisch laden van de PHP-klasse. Naamruimte wordt beschouwd als een verzameling objecten die zich op een specifieke locatie in het bestandssysteem bevinden. Normaal gesproken bevinden alle objecten zich in het bestandssysteem op basis van hun betekenis, in mappen en in bestanden met een specifieke naam.

De code aan de linkerkant geeft de creatie van de vereiste vijf objecten aan, maar waar ze zich precies bevinden, wordt niet aangegeven. De code aan de rechterkant toont de tekst van de autoloader (hoofdscript), die bij het laden van klassen (objecten) automatisch het vereiste pad naar de locatie van het object en de .php-bestandsextensie vervangt.

Voorbeeld van meerdere naamruimten

De PhpOffice/PhpWord-bibliotheek is een goed voorbeeld van het gebruik van een complexe hiërarchie van meerdere naamruimten. De elementenmap bevat vrijwel het volledige scala aan elementen die beschikbaar zijn bij het maken van een *.docx-document (MS Word), andere mappen bevatten de nodige hulpmiddelen voor het werken met elementen, paragrafen en tabellen.

Eigenlijk werd de bibliotheek in de projectmap geplaatst omdat de functionaliteitsruimte van PhpOffice / PhpWord moest worden aangevuld met specifieke tools om uiteindelijk je eigen versie van een soortgelijk product te creëren.

Veel klassen met verschillende naamruimten laden

Het gebruik van PHP-naamruimte-autoload, wanneer het nodig is om veel klassen te laden, en de hiërarchie van het ontwikkelde systeem van objecten behoorlijk complex en moeilijk voor te stellen is, leidt tot de noodzaak om rigide structuren te creëren.

De oriëntatie van de ontwikkelaar (die het product gebruikt om verder te werken) is alleen mogelijk in de context van semantiek (begrip van het project), die wordt weergegeven door passende woordcombinaties die de werkelijke betekenis en relaties van objecten weerspiegelen.

De noodzaak om de bibliotheek in een individueel project te gebruiken leidt tot het oplossen van het probleem van het combineren van de naamruimten van de ontwikkelaar en PhpOffice / PhpWord-auteur. De beste manier is om dit product (de ruimtes en objecten) in een eigen projectruimte te plaatsen.

Het is belangrijk op te merken dat het niet mogelijk zal zijn om de naamruimten van dit product te wijzigen op het niveau van de abstracte elementen en het laden van klassen. Dit geeft aan dat het gebruik van interne naamruimten in PHP-naamruimte mogelijk niet voldoende abstract en universeel is.

Bestandssysteem en lokalisatie van spaties

In essentie zijn naamruimten een “tekening” van het pad in het bestandssysteem naar het gewenste object. Het gebruik van bestandsnamen als objectnamen is natuurlijk en vertrouwd. Het gebruik van mapnamen als naamruimtenaamgeving is objectief.

De ‘houten’ organisatie van informatie is nogal omslachtig in het gebruik en bemoeilijkt de ontwikkeling, maar het is een natuurlijke representatie voor systemen van objecten.

Het probleem is dat de ontwikkelingsfase wordt vertegenwoordigd door een specifieke code-editor, die zowel de zichtbare weergave van mappen als de inhoud van een specifieke map combineert, maar er is nog geen editor die end-to-end beweging door objecten en door middel van mappen.

Het probleem van abstractie en universaliteit

Geaccepteerd door het bewustzijn en de doelstelling van de ontwikkelaar in werkelijkheid:

• biedt abstractie en de mogelijkheid om informatie te manipuleren volgens de werkelijke semantiek ervan;
• naamruimten weerspiegelen de positie van scripts, objecten en gedeeltelijk de betekenis van het project in het bestandssysteem

Door de OOP-abstractie te verbinden met objectnamen (bestanden) en deze over het bestandssysteem (mappen) te leggen met adequate naamruimtevorming (paden + namen), kunt u de vorming van naamruimten tijdens de uitvoering van het script controleren.

Programmeren heeft al een krachtige ontwikkelingsdynamiek gekregen, maar als we het proces en de werklast van de ontwikkelingsfase overbrengen van een teksteditor (waarin scripts worden gemaakt en in mappenbomen worden geplaatst) naar het idee om een ​​code te genereren die laat zich verbeteren en op de juiste plaats in het bestandssysteem plaatsen - programmeren zal naar nieuwe hoogten stijgen.

Vandaag zullen we, in de stijl van complete idioten, in de goede zin van het woord, proberen te begrijpen wat naamruimten zijn in PHP 5.

Wat is een naamruimte in PHP 5

Dit betekent, voor complete idioten, wederom alleen in de goede zin van het woord, laten we zeggen dat naamruimten in PHP 5 (en in C en C++) lijken op de namen van steden in Rusland of Oekraïne, die straatnamen bevatten. In dezelfde stad, maar ook in de naamruimte, bijvoorbeeld Moskou, kunnen er bijvoorbeeld niet meerdere straatnamen zijn met de naam "Putlerovskaya 666" - bent u het daar mee eens? OK.

Naast de gedefinieerde naamruimten is er ook een globale PHP-naamruimte, waarin alle basisfuncties en klassen rondhangen, evenals degene die zijn gedefinieerd in de opgenomen bestanden en waaraan geen specifieke naamruimte is toegewezen. Naar analogie met het echte leven kunnen we zeggen dat daklozen, gopniks, prostituees en ander gespuis in wezen dezelfde functies en klassen zijn die geen specifieke woonplaats toegewezen kregen ( naamruimte) en die eenvoudigweg in de mondiale ruimte van Rusland leven – oftewel “mijn adres is geen huis of straat, mijn adres is de Sovjet-Unie.”

Globale naamruimte in PHP 5

Voorheen, vóór PHP 5.3, zoals nu het geval is, werden alle constanten, functies en klassen in de opgenomen bestanden automatisch in de algemene PHP-ruimte geplaatst.

Dus als het bestand Liba1.php met constanten, functies en klassen:

require_once ("Liba1.php" );

const MYCONST = "MYCONST-INHOUD";

functie mijnFunctie() ( retourneer __FUNCTION__ ; ) klasse MijnKlasse ( statische functie whoAmI() ( retourneer __METHOD__ ; ) ) We nemen ze op in ons uitvoerbare bestand, waarna ze zich in de globale naamruimte bevinden en beschikbaar zijn voor directe oproepen: functie mijnFunctie() ( retourneer __FUNCTION__ ; ) klasse MijnKlasse ( statische functie whoAmI() ( retourneer __METHOD__ ; ) )\N" functie mijnFunctie() ( retourneer __FUNCTION__ ; ) klasse MijnKlasse ( statische functie whoAmI() ( retourneer __METHOD__ ; ) );

echo mijnFunctie() . "; echo MijnKlasse::wieAmI().).

"

;

// of $obj = nieuwe MijnKlasse() ;

echo $obj -> whoAmI () ;

Houd er rekening mee dat volgens de nieuwste PSR-4-standaard (http://www.php-fig.org/psr/psr-4/) klassen een naam moeten krijgen met een hoofdletter, net als de bestanden die ze bevatten, en methoden (

De klasse MyClass zelf, zijn methoden (functies) en eigenschappen (variabelen, constanten), zijn alleen toegankelijk vanuit de app-naamruimte.

Om MyClass direct te gebruiken vanuit de App-naamruimte in ons uitvoerbare bestand/script, moeten we ofwel dezelfde "naamruimte App;" erin declareren, of "use App\MyClass;" gebruiken:

wiebenik();

In dit voorbeeld laden we onze MyClass.php vanuit dezelfde map waar het uitvoerbare bestand zich bevindt, d.w.z. zonder te voldoen aan de PSR-4-standaard. In theorie zou "naamruimte App;" in het klassenbestand moeten worden gedeclareerd, en niet in het uitvoerbare bestand, en zou App (voor succesvol automatisch laden) een directory moeten zijn, en de klassenaam "class MyClass (...)" corresponderend met de bestandsnaam MyClass.php , die beschikbaar zou moeten zijn op App/MyClass.php.

Als we MyClass.php handmatig laden en "namespace App;" of "use App\MyClass;" niet declareren, krijgen we de melding "Fatal error: Class "MyClass" not found" omdat de naamruimte "namespace App" is gedeclareerd in de class-bestand MyClass.php ; " (App) en alleen daaruit zal de klasse MyClass beschikbaar zijn, - uiteraard als een klasse met dezelfde naam (MyClass) niet in de globale ruimte wordt gedeclareerd.

Om klassen uit naamruimten te gebruiken, moeten we PHP vragen dit te doen met de instructies "use App\MyClass;" of "namespace App;".

Voor succesvol automatisch laden moeten we voldoen aan de PSR-4-standaard en klassebestanden plaatsen in mappen waarvan de namen overeenkomen met de gedeclareerde naamruimte. Bijvoorbeeld:

MyClass-klassenaamruimte: " naamruimte App; " Fysieke bestandslocatie: App/MyClass.php MyClass-klassenaamruimte: " naamruimte App\Liba1; " Fysieke bestandslocatie: App/Liba1/MyClass.php MyClass-klassenaamruimte: " naamruimte App \Vasya\ Liba1; "Fysieke locatie van het bestand: App/Vasya/Liba1/MyClass.php

Laten we wat meer praten over het "automatisch laden" van klassen in PHP 5...

Gebruik instructie in PHP 5

Met de use-instructie hebben we toegang tot een andere naamruimte of klasse vanuit een andere naamruimte.

Noch constanten, noch functies kunnen worden geïmporteerd met behulp van de use-instructie. Alleen klassenamen en naamruimten worden beïnvloed door de use-instructie. Hoewel het lijkt alsof het vanaf PHP 5.6+ mogelijk is om functies en constanten te importeren.

• Importeer en maak een alias voor een klas: gebruik App\Liba1\MyClass als MyAlias;
• Klasse importeren: gebruik App\Liba1\MijnKlasse;
• De naamruimte zelf importeren: gebruik App\Liba1;
• Een globale klasse importeren: gebruik ArrayObject;

Iemand vraagt ​​zich misschien af: “Waarom hebben we in vredesnaam een ​​globale klasse nodig?”, maar we hebben het nodig om er toegang toe te krijgen vanuit een bepaalde naamruimte, bijvoorbeeld:

Omdat we ons in de naamruimte "Vasya" bevinden, en PHP altijd onder de huidige naamruimte werkt, eindigt de uitvoering van bovenstaande code met de foutmelding "Fatale fout: Class "Vasya\ArrayObject" not found in". Om toegang te krijgen tot de klasse ArrayObject terwijl we ons in de Vasya-naamruimte bevinden, moeten we " use ArrayObject; " gebruiken (commentaar verwijderen) of de klassenaam transformeren met een backslash \ArrayObject .

• Met de klasse ArrayObject kunt u met objecten werken alsof het arrays zijn.
• PHP: Naamruimten gebruiken: Een naamalias importeren/aanmaken - Handleiding
• PHP: Naamruimten gebruiken: doorgeven aan globale functie/constante - Handleiding
• Veelgestelde vragen (FAQ): dingen die u moet weten over naamruimten

Klassen automatisch laden in PHP 5

Eén ding om te onthouden is dat PHP altijd in de huidige naamruimte draait. Dit betekent dat als we de naamruimte "namespace Vasya;" hebben gedeclareerd, een klasseobject "$obj = new MyClass();" proberen te maken, wanneer we de autoloader-functie "__autoload()" of "spl_autoload_register()" gebruiken, een poging doen zal worden gemaakt om het bestand te verbinden met Vasya/MyClass.php. Bijvoorbeeld:

// Gebruik Vasya's naamruimte);

retourneer waar; ) retourneert onwaar;).

));

$obj = nieuwe MijnKlasse() ;

echo $obj -> whoAmI () ;

Voor het automatisch laden van klassen verdient de functie spl_autoload_register() de voorkeur boven __autoload() . De functie __autoload() is verouderd en kan in de toekomst worden stopgezet of geheel verwijderd. Sinds PHP 5.3.0 is het mogelijk geworden om naamloze functies te gebruiken ( ook bekend als "functie ()()".

Resultaten De introductie van naamruimten in PHP is zeker een positieve stap. Als ik iets mis, corrigeer mij dan met uw opmerkingen. P.S. Het artikel is geschreven op verzoek van werknemers die niet met de officiële documentatie overweg konden. Hallo. In het artikel van vandaag zullen we kijken naar:, wat zijn naamruimten in PHP Als u het al langere tijd gebruikt

Naamruimte- dit is een soort opslag die is gemaakt voor de abstracte groepering van unieke identificatiegegevens (namen).

Die. als je gebruikt naamruimten, dan kunt u veilig bibliotheken van derden verbinden en hoeft u niet bang te zijn dat ze dezelfde namen zullen hebben als in uw code. Laten we eindigen met de theorie en verder gaan met de praktijk.

Laten we een bestand maken mijnklasse.php met deze inhoud

naamruimte mijn\oneProject;
klasse MijnKlasse ( )
?>

Hier hebben we een klasse in de naamruimte gemaakt mijn\oneProject. Trouwens, je moet precies de backslash schrijven. Raak niet in de war!

Nu in bestand index.php laten we het volgende schrijven

require_once("mijnklasse.php");
$mc = nieuwe MijnKlasse(); // Fout: klasse niet gevonden
$mc = nieuw mijn\oneProject\MijnKlasse(); // alles werkt
?>

Zoals u kunt zien, is het nu niet mogelijk om zomaar een klasse te maken, u moet opgeven waarin naamruimte hij ligt.

Wij kunnen er meerdere tegelijk specificeren naamruimten in één bestand

naamruimte Project;

Const CONNECT_OK = 1;
klasse Verbinding ( )
functie verbinden() ( )

NaamruimteAnotherProject;

Const CONNECT_OK = 1;
klasse Verbinding ( )
functie verbinden() ( )
?>

Ondanks het feit dat we absoluut identieke namen van klassen, functies en constanten hebben, zullen we geen naamconflict hebben, omdat ze liggen in verschillende ruimtes.

We kunnen ook de syntaxis van haakjes gebruiken.

naamruimte Project (

Const CONNECT_OK = 1;
klasse Verbinding ( )
functie verbinden() ( )
}

Naamruimte AnotherProject (

Const CONNECT_OK = 1;
klasse Verbinding ( )
functie verbinden() ( )
}
?>

Als je de code combineert in globale naamruimte met code in andere spaties, wordt alleen de syntaxis tussen haakjes gebruikt.

naamruimte Project (

Const CONNECT_OK = 1;
klasse Verbinding ( )
functie verbinden() ( )
}

Naamruimte ( // globale code
sessie_start();
$a = Project\connect();
echo Project\Verbinding::start();
}
?>

Vergeet ook niet dat het definiëren van een naamruimte altijd de eerste regel code moet zijn. Als u zo schrijft, zal er een fout optreden

Om erachter te komen in welke naamruimte u zich momenteel bevindt, kunt u de constante gebruiken __NAAMRUIMTE__

naamruimte Project;
echo """, __NAMESPACE__, """; // zal "Project" afdrukken
?>

Met deze constante kun je bijvoorbeeld dynamisch namen construeren

naamruimte Project;

Functie incl($classname) (
$a = __NAMESPACE__ . "\\" . $klassenaam;
retourneer nieuwe $a;
}
?>

Zo, dat is alles voor vandaag. Meer informatie en praktische kennis kunt u opdoen door de cursus te volgen

PHP gaf ons vanaf versie 5.3 naamruimten. Sindsdien is er een trage en verhitte discussie geweest over het gebruik van deze naamruimte?
Sommige raamwerken, zoals Symphony, Laravel en natuurlijk Zend, hebben deze technologie overgenomen.
Dit alles past min of meer in het MVC-schema. Er blijft één, waarschijnlijk eeuwige, discussie over: wat zou het belangrijkste huwelijkspaar van de applicatie moeten zijn: Model en Controller?
Sommigen vertellen ons dat het Model stevig en dik moet zijn en met haar een slanke en magere Controleur. In één woord: matriarchaat.
Anderen zijn daarentegen van mening dat de Controleur alles moet beheren en bevelen, zodat hij solide en goed gevoed blijkt te zijn. En met hem is een mager, slank Model, wiens taak neerkomt op geven en brengen. Dit is patriarchaat.
Dus wat is beter in het MVC-schema? Patriarchaat of matriarchaat?
Laten we dit eens bekijken vanuit het gezichtspunt van het opbouwen van een gezinseenheid op basis van democratie. En laat Namespace ons hierbij helpen.

We houden niet van dikke, onhandige controllers die, als een stier in een porseleinkast, de hele applicatie kunnen verpletteren als je onzorgvuldig bent.
Wij houden ook niet van dikke modellen. Nou, wie vindt ze leuk? Ze moeten het podium waardig zijn!
Laten we proberen, met de hulp van Namespace, zoals met een goede matchmaker, een harmonieus gezin te creëren.

Laten we eerst het skelet van de applicatie maken. Hoe banaal het ook mag zijn, laat het een blog zijn.

We hebben een basisstructuur gecreëerd waarin:

• Blog is de opslag van onze applicatie;
• Weergaven en sjablonen - opslag van weergaven en sjablonen;
• Hulpprogramma - opslagplaats van gedeelde bibliotheken;
• index.php - bootstrap-script;
• Post - dit is waar de familie-idylle van de Controller en het Model zou moeten plaatsvinden.

Met index.php is alles eenvoudig:

loop(); /* * einde van index.php */

We bepalen de benodigde paden en creëren een autoloader.
De autoloader laadt de vereiste klassen, die zich in een maphiërarchie bevinden volgens de klassenaamruimte. De klasse BlogPostServicesView wordt bijvoorbeeld opgezocht in Blog/Post/Services.
En hier is de eerste ontmoeting met Namespace.
Wanneer we index.php starten, maken we een exemplaar van de Blog-applicatie, waarvan de klasse wordt geladen vanuit Blog/Blog.php.
Laten we naar hem kijken.

bericht = nieuw bericht();

) public function run() ( $this->post->view->all(); ) )//end class Blog
Bij het maken van de Blog-klasse injecteren we er een Post-klasse in met Naamruimte BlogPost en de autoloader laadt deze vanuit Blog/Post/Post.php.

Waarschijnlijk kan deze klasse een Controller worden genoemd,

bekijken = nieuwe weergave();
)//einde lespost

De Post-entiteit omvat:

- de structuur van het gegevensrecord zelf - BlogPostEntitiesPostEntity.php

Het systeem voor interactie met de database - BlogPostRepositoriesDB.php - hier is het, ons dunne, elegante model,
Geef het gewoon en breng het, en meer niet!

dbh = nieuwe PDO("mysql:host=localhost;dbname=test", $user, $pass, array(PDO::ATTR_PERSISTENT => true));
) catch (PDOException $e) ( echo "Error!: " . $e->getMessage() . "

"; die(); ) )//end __construct public function survey() ( $query_view = $this->dbh->prepare("SELECT * from posts"); $query_view->execute(); return $query_view- >fetchAll(PDO::FETCH_CLASS, "BlogPostEntitiesPostEntity" )//eind enquête )//eind klasse Db
Hierdoor hebben we een applicatiestructuur kunnen creëren waarin alle componenten goed met elkaar verbonden zijn, terwijl we een duidelijke scheiding van klassen hebben bereikt, waarbij elke klasse zijn eigen taak vervult. Onze controller is dun en tegelijkertijd krachtig. Het model past bij hem. Ideaal gezin!

En dat allemaal dankzij Namespace.
Ik beweer niet dat het raamwerk in veel gevallen handig is. Maar kijk, Naamruimte doet je nergens aan denken?
Een duidelijke indeling in klassen, een strikte en tegelijkertijd flexibele hiërarchie van mappen en klassen, volledig ondergeschikt aan de ontwikkelaar.
Soms is er niet zo'n belangrijke add-on in de vorm van honderden bestanden en klassen in de vorm van een raamwerk.

De afwezigheid van een Procrusteaans bed van regels voor de interactie van klassen en componenten.
Het artikel is geïnspireerd op de gedachten over dit onderwerp van Taylor Otwell, de auteur van het Laravel-framework, waarvoor veel dank aan hem.

Adres van de voorbeeldbroncode op GitHub.
Ik heb onlangs mijn project ingekapseld in een naamruimte en kwam het probleem tegen van het ontbreken van de juiste documentatie. Alles wat we hebben kunnen vinden dateert van ongeveer 2009, en het is bijna 2012... In het gevonden materiaal zijn er veel niet-werkende plaatsen die iets gebruiken dat niet in de huidige versie van php staat. In dit verband zou ik graag enig licht willen werpen op deze kwestie.

Naamruimte is een set, wat een model, abstracte opslag of omgeving betekent die is gemaakt voor de logische groepering van unieke identificatiegegevens (dat wil zeggen namen). Een ID die in een naamruimte is gedefinieerd, wordt aan die naamruimte gekoppeld. Dezelfde identificatie kan onafhankelijk in meerdere ruimtes worden gedefinieerd. Een waarde die is gekoppeld aan een identificator die in de ene naamruimte is gedefinieerd, kan dus (of kan niet) dezelfde (of eerder verschillende) betekenis hebben als dezelfde identificator die in een andere naamruimte is gedefinieerd. Naamruimtebewuste talen definiëren regels die aangeven tot welke naamruimte een identificatie behoort (dat wil zeggen de definitie ervan).wiki

Is alles duidelijk? Het is eigenlijk eenvoudig. Vóór versie 5.3 waren er slechts twee spaties in php: globaal (waarin je hoofdcode werd uitgevoerd) en lokaal (waarin functievariabelen werden gedefinieerd).

Sinds versie 5.3 is alles veranderd. Nu kunt u uw naamruimte definiëren waarin uw klassen, methoden, enz. zullen bestaan.


Ik hoop dat het een beetje duidelijker is geworden.

Ik heb de klassen specifiek hetzelfde genoemd. Omdat ze in verschillende ruimtes zijn gedefinieerd, zijn het twee verschillende klassen, ondanks dezelfde namen. Het hoofdscript functioneert nog steeds in de globale ruimte, hier is niets veranderd en er kunnen nog steeds klassen en functies in worden gedefinieerd. Dus waar zijn spaties dan voor? Allereerst moet u ervoor zorgen dat wanneer u een bestand met een bepaald raamwerk of een bibliotheek opneemt, uw klassen de klassen van het raamwerk niet zullen overschrijven, of andersom.

Om klassen te gebruiken die in uw naamruimte zijn gedefinieerd, moet u de ruimte die u definieert op de juiste plaats in de globale ruimte importeren (meestal doe ik dit het liefst aan het begin van het bestand).

Aandacht: om de een of andere reden staat php het gebruik van het trefwoord niet toe gebruik in conditieblokken en lussen

Laten we het voorbeeld uit de afbeeldingen nemen en het in code implementeren:

Aandacht: het trefwoord naamruimte moet zich helemaal aan het begin van het bestand bevinden, onmiddellijk erna
bestand A.php
B.php-bestand
Een alternatieve syntaxis is mogelijk:
Het wordt aanbevolen om elke naamruimte in een afzonderlijk bestand te declareren. Hoewel het in één keer mogelijk is, wordt het ten strengste afgeraden!
Laten we nu naar het derde bestand gaan, waarin ons hoofdscript zal functioneren
index.php
Het lijkt erop dat dit een voordeel is, er wordt alleen meer code toegevoegd, maar dit is niet helemaal waar, iets verderop zal ik een voorbeeld geven van een autoload-klasse, waarmee de lijnen die bestanden met klassen verbinden overbodig zullen zijn.
Laten we nu eens naar onze lessen kijken.

Aandacht: met behulp van de scope-resolutie-operator (::) in php-naamruimten niet toegestaan! Het enige waarvoor het geschikt is, is toegang tot statische klassenmethoden en constanten. In eerste instantie wilden ze het gebruiken voor de naamruimte, maar toen besloten ze dit niet te doen vanwege problemen die zich voordeden. Daarom is een constructie als A::A::say(); is ongeldig en resulteert in een fout.

Voor naamruimten moet u het backslash-teken "\" gebruiken

Aandacht: Om misverstanden te voorkomen, is het noodzakelijk om dit teken te escapen wanneer het in strings wordt gebruikt: "\\"

Naamruimten kunnen in elkaar worden genest, laten we dit aan ons A.php-bestand toevoegen:
en in de index schrijven we het volgende:

Een belangrijk punt is het gebruik van aliassen voor geïmporteerde ruimtes. Je zou A\subA::say(); U zult het ermee eens zijn dat het moeilijk is om telkens volledige paden naar spaties te schrijven; om dit te voorkomen zijn er aliassen geïntroduceerd. Bij het compileren gebeurt het volgende: in plaats van de alias sub wordt A\subA vervangen, dus we krijgen de aanroep A\subA::say();

Wat gebeurt er dan bij het aanroepen van functies die in de globale ruimte zijn gedefinieerd? PHP zoekt eerst naar een functie binnen de ruimte waar je momenteel werkt, en als het deze niet vindt, gaat het naar de globale scope. Om direct aan te geven dat je een globale functie gebruikt, moet je deze vooraf laten gaan door een backslash.

Om problemen met het automatisch laden van klassen uit spaties te voorkomen, moet het bestandssysteem op dezelfde manier worden georganiseerd als de organisatie van spaties. We hebben bijvoorbeeld klassen in de hoofdmap, waar onze klassen worden opgeslagen, waarna onze ruimtes als volgt kunnen worden georganiseerd
klassen\A\A.php
klassen\A\sub\A.php (sub-subruimte wordt in een apart bestand geplaatst)
klassen\B\B.php

PHP heeft een magische constante __NAMESPACE__ die de naam van de huidige ruimte bevat.

En nu over automatisch laden.

De onderstaande klasse is niet van mij, ik heb hem gewoon laten werken en een beetje verbeterd, vanaf hier overgenomen.

Aandacht: Om uw klassen te kunnen laden, moet de klassenaam overeenkomen met de bestandsnaam!

" .$bestand ." in " .$filepath)); if (file_exists($filepath)) ( if(Autoloader::debug) Autoloader::StPutFile(("connected " .$filepath)); $flag = FALSE; require_once($filepath); break; ) Autoloader::recursive_autoload($file, $path2, &$flag ) ) closedir($handle ) privé statische functie StPutFile($data) ( $dir = $_SERVER["DOCUMENT_ROOT"] ." / Log/Log.html"; $file = fopen($dir, "a"); kudde($file, LOCK_EX); fwrite($file, ("║" .$data ."=>" .date(" d.m.Y Zijn") ."
║
" .PHP_EOL)); kudde($file, LOCK_UN); fclose ($bestand); ) ) \spl_autoload_register("uwNaamSpace\Autoloader::autoload"); )
Als je kijkt naar de namen van de klassen die binnenkomen om te laden, zie je dat elke klasse wordt voorafgegaan door een prefix uit de naamruimte die in gebruik is opgegeven. Dit is de reden waarom ik aanbeveel om de locatie van bestanden in mappen te gebruiken die vergelijkbaar zijn met de naamruimte; dit versnelt het zoeken naar een of twee iteraties.

Nu kan onze index als volgt worden geschreven:
Nu worden alle klassen en interfaces die u gaat gebruiken automatisch geladen.

Laten we, om enkele van de dynamische mogelijkheden van de taal met spaties te demonstreren, een andere klasse declareren:
test.php

Index.php
zegNaam("test"); //of je kunt dit doen test\sayName("test2"); //of zoals dit $obj::sayName("test"); //of je kunt deze test doen::sayName("test2");

Ik hoop dat mijn artikel voor iemand nuttig zal zijn.