(PHP 5 >= 5.3.0, PHP 7)

სანამ სახელთა სივრცის გამოყენებას განვიხილავთ, მნიშვნელოვანია გვესმოდეს, თუ როგორ იცის PHP-მა სახელთა სივრცის რომელ ელემენტს ითხოვს თქვენი კოდი. მარტივი ანალოგია შეიძლება გაკეთდეს PHP სახელთა სივრცესა და ფაილურ სისტემას შორის. ფაილურ სისტემაში ფაილზე წვდომის სამი გზა არსებობს:

1. ფაილის შედარებითი სახელი, როგორიცაა foo.txt. ეს წყვეტს მიმდინარე დირექტორია/foo.txtსადაც currentdirectory არის დირექტორია, რომელიც ამჟამად დაკავებულია. ასე რომ, თუ მიმდინარე დირექტორია არის /სახლი/ფუ, სახელი გადაწყვეტს /home/foo/foo.txt.
2. ბილიკის შედარებითი სახელი, როგორიცაა ქვედირექტორია/foo.txt. ეს წყვეტს currentdirectory/subdirectory/foo.txt.
3. ბილიკის აბსოლუტური სახელი, როგორიცაა /main/foo.txt. ეს წყვეტს /main/foo.txt.

იგივე პრინციპი შეიძლება გამოყენებულ იქნას PHP-ში სახელთა სივრცის ელემენტებზე. მაგალითად, კლასის სახელი შეიძლება მოიხსენიებოდეს სამი გზით:

1. არაკვალიფიცირებული სახელი, ან კლასის არაპრეფიქსის მსგავსი სახელი $a = new foo();ან foo::staticmethod(); მიმდინარე სახელთა სივრცე, ეს გადაწყვეტს მიმდინარე სახელთა სივრცე\foo ფუ. ერთი გაფრთხილება: ფუნქციების და მუდმივების არაკვალიფიცირებული სახელები გადაიჭრება გლობალურ ფუნქციებსა და მუდმივებზე, თუ სახელთა სივრცის ფუნქცია ან მუდმივი არ არის განსაზღვრული. დეტალებისთვის იხილეთ სახელების სივრცის გამოყენება: დაბრუნება გლობალურ ფუნქციაზე/მუდმივზე.
2. კვალიფიციური სახელი, ან კლასის პრეფიქსის მსგავსი სახელი $a = new subnamespace\foo();ან subnamespace\foo::staticmethod();. თუ მიმდინარე სახელთა სივრცე არის მიმდინარე სახელთა სივრცე, ეს გადაწყვეტს currentnamespace\subnamespace\foo. თუ კოდი არის გლობალური, არასახელთაშორისი კოდი, ეს გადაწყდება ქვესახელთა სივრცე\foo.
3. სრულად კვალიფიციური სახელი, ან პრეფიქსის სახელი გლობალური პრეფიქსის ოპერატორის მსგავსი $a = new \currentnamespace\foo();ან \currentnamespace\foo::staticmethod();. ეს ყოველთვის წყდება კოდში მითითებულ სიტყვასიტყვით, მიმდინარე სახელთა სივრცე\foo.

აქ მოცემულია სამი სახის სინტაქსის მაგალითი რეალურ კოდში:

სახელთა სივრცე Foo\Bar\subnamespace;

const FOO = 1;
ფუნქცია foo()()
კლასის საკვები
{
}
?>

სახელთა სივრცე Foo\Bar;
მოიცავს "file1.php" ;

const FOO = 2;
ფუნქცია foo()()
კლასის საკვები
{
სტატიკური ფუნქცია staticmethod()()
}

/* არაკვალიფიციური სახელი */
foo(); foo::staticmethod(); echo FOO;

/* კვალიფიციური სახელი */
subnamespace\foo(); // წყვეტს ფუნქციას Foo\Bar\subnamespace\foo
subnamespace\foo::staticmethod(); // გადადის კლასში Foo\Bar\subnamespace\foo,
// მეთოდის სტატიკური მეთოდი
echo subnamespace\FOO; // გადადის მუდმივზე Foo\Bar\subnamespace\FOO

/* სრულად კვალიფიციური სახელი */
\foo\bar\foo(); // წყვეტს ფუნქციას Foo\Bar\foo
\foo\bar\foo::staticmethod(); // გადადის კლასში Foo\Bar\foo, მეთოდი staticmethod
echo\Foo\Bar\FOO; // გადადის მუდმივზე Foo\Bar\FOO
?>

გაითვალისწინეთ, რომ ნებისმიერი გლობალური კლასის, ფუნქციის ან მუდმივის წვდომისთვის შეიძლება გამოყენებულ იქნას სრულად კვალიფიციური სახელი, როგორიცაა \strlen()ან \გამონაკლისიან \INI_ALL. ?>

PHP-მა, დაწყებული 5.3 ვერსიით, მოგვცა სახელთა სივრცეები. მას შემდეგ, იყო დუნე და მწვავე დისკუსია იმის შესახებ, თუ როგორ გამოვიყენოთ ეს სახელთა სივრცე?
ზოგიერთმა ჩარჩომ, როგორიცაა Symphony, Laravel და, რა თქმა უნდა, Zend, მიიღო ეს ტექნოლოგია.
ეს ყველაფერი მეტ-ნაკლებად ჯდება MVC სქემაში. რჩება ერთი, ალბათ მარადიული დებატები: როგორი უნდა იყოს განაცხადის მთავარი საქორწინო წყვილი - მოდელი და კონტროლერი?
ზოგი გვეუბნება, რომ მოდელი უნდა იყოს მსუქანი და მსუქანი და მასთან ერთად სუსტი და გამხდარი კონტროლერი. ერთი სიტყვით - მატრიარქატი.
სხვები, პირიქით, თვლიან, რომ კონტროლიორმა უნდა მართოს და მართოს ყველაფერი, ასე რომ, ის აღმოჩნდება მყარი და კარგად გამოკვებადი. და მასთან ერთად არის გამხდარი, გამხდარი მოდელი, რომლის ამოცანაც მიცემა და მოტანა სრულდება. ეს არის პატრიარქატი.
ასე რომ, რომელია უკეთესი MVC სქემაში? პატრიარქატი თუ მატრიარქატი?
ამას შევხედოთ დემოკრატიაზე დაფუძნებული ოჯახის ერთეულის აგების კუთხით. და მოდით, Namespace დაგვეხმაროს ამაში.

ჩვენ არ მოგვწონს სქელი, უხერხული კონტროლერები, რომლებსაც, როგორც ხარი ჩინურ მაღაზიაში, შეუძლიათ გაანადგურონ მთელი აპლიკაცია, თუ უყურადღებოდ იქნებით.
არც მსუქანი მოდელები მოგვწონს. აბა, ვის მოსწონს ისინი? ისინი უნდა იყვნენ პოდიუმის ღირსნი!
შევეცადოთ, Namespace-ის დახმარებით, როგორც კარგ მაჭანკალს, შევქმნათ ჰარმონიული ოჯახი.

პირველი, მოდით შევქმნათ აპლიკაციის ჩონჩხი. რაც არ უნდა ბანალური იყოს, ბლოგი იყოს.

ჩვენ შევქმენით ძირითადი სტრუქტურა, სადაც:

• ბლოგი არის ჩვენი აპლიკაციის საცავი;
• ხედები და შაბლონები - ნახვების და შაბლონების შენახვა;
• კომუნალური - საერთო ბიბლიოთეკების საცავი;
• index.php - bootstrap სკრიპტი;
• პოსტი - სწორედ აქ უნდა მოხდეს კონტროლერისა და მოდელის ოჯახური იდილია.

index.php-ით ყველაფერი მარტივია:

run(); /* * index.php */

ჩვენ განვსაზღვრავთ საჭირო ბილიკებს და ვქმნით ავტოჩამტვირთველს.
ავტოჩამტვირთველი ატვირთავს საჭირო კლასებს, რომლებიც განლაგებულია საქაღალდეში იერარქიაში კლასის სახელთა სივრცის მიხედვით. მაგალითად, BlogPostServicesView კლასი მოიძებნება Blog/Post/Services-ში.
და აი, პირველი შეხვედრა სახელთა სივრცესთან.
როდესაც ვიწყებთ index.php, ვქმნით Blog აპლიკაციის ინსტანციას, რომლის კლასი იტვირთება Blog/Blog.php-დან.
მოდით შევხედოთ მას.

პოსტი = ახალი პოსტი();

) საჯარო ფუნქცია run() ( $this->post->view->all(); ) )//end class ბლოგი
Blog კლასის შექმნისას მასში ჩავრთავთ Post კლასს Namespace BlogPost-ით და ავტოჩამტვირთველი იტვირთება მას Blog/Post/Post.php-დან.

ალბათ ამ კლასს შეიძლება ეწოდოს Controller,

ხედი = new View();
) )//კლასის დასასრული პოსტი

ფოსტის ერთეული მოიცავს:

- თავად მონაცემთა ჩანაწერის სტრუქტურა - BlogPostEntitiesPostEntity.php

სერვისები, რომლებიც ემსახურებიან კონტროლერის მოთხოვნებს - BlogPostServicesView.php (მაგალითად, ერთ-ერთი სერვისი)
db = new DB();

)//ბოლო __აშენება საჯარო ფუნქცია all() ( $posts = $this->db->survey(); Contemplate::compose(array("header" => "header", "main" => "main", "footer" => "footer",), array("posts" => $posts, "title" => "Viper საიტი",) ) )//კლასის ბოლოს PostView
მონაცემთა ბაზასთან ურთიერთობის სისტემა - BlogPostRepositoriesDB.php - აი, ეს არის ჩვენი თხელი, ელეგანტური მოდელი,

უბრალოდ მიეცი და მოიტანე და მეტი არაფერი!
dbh = new PDO ("mysql:host=localhost;dbname=test", $user, $pass, მასივი (PDO::ATTR_PERSISTENT => true));

) catch (PDOException $e) (echo "Error!:" . $e->getMessage() ."
"; die(); ) )//end __construct public function survey() ( $query_view = $this->dbh->prepare("SELECT * პოსტებიდან"); $query_view->execute(); დაბრუნება $query_view- >fetchAll(PDO::FETCH_CLASS, "BlogPostEntitiesPostEntity" )//გამოკითხვის დასასრული )//კლასის დასასრული Db
შედეგად, ჩვენ შევძელით შეგვექმნა აპლიკაციის სტრუქტურა, სადაც ყველა კომპონენტი კარგად არის დაკავშირებული, ხოლო ჩვენ მივაღწიეთ კლასების მკაფიო გამიჯვნას, სადაც თითოეული კლასი ასრულებს თავის დავალებას. ჩვენი კონტროლერი არის თხელი და ამავე დროს ძლიერი. მოდელი მას ემთხვევა. იდეალური ოჯახი!
და ეს ყველაფერი სახელების სივრცის წყალობით.

მე არ ვკამათობ, ხშირ შემთხვევაში ჩარჩო მოსახერხებელია. მაგრამ ნახეთ, სახელთა სივრცე არაფერს გახსენებს?
მკაფიო დაყოფა კლასებად, დირექტორიებისა და კლასების მკაცრი და ამავე დროს მოქნილი იერარქია, რომელიც მთლიანად ექვემდებარება დეველოპერს.

მე ცოტა ხნის წინ ჩავყარე ჩემი პროექტი სახელთა სივრცეში და წავაწყდი სათანადო დოკუმენტაციის არარსებობის პრობლემას. ყველაფერი, რისი პოვნაც მოვახერხეთ, თარიღდება დაახლოებით 2009 წლით, და ეს თითქმის 2012 წლითაა... ნაპოვნი მასალაში არის უამრავი არასამუშაო ადგილი, რომელიც იყენებს იმას, რაც არ არის php-ის მიმდინარე ვერსიაში. ამასთან დაკავშირებით, მსურს ამ საკითხს გარკვეული სინათლე მოჰფინოს.
მაშ, რა არის სახელთა სივრცე ან სახელთა სივრცე? დიდი ვიკიპედია მათ ასე განსაზღვრავს:

სახელთა სივრცე არის ნაკრები, რაც ნიშნავს მოდელს, აბსტრაქტულ საცავს ან გარემოს, რომელიც შექმნილ იქნა უნიკალური იდენტიფიკატორების (ანუ სახელების) ლოგიკური დაჯგუფებისთვის. სახელთა სივრცეში განსაზღვრული იდენტიფიკატორი ასოცირდება ამ სახელთა სივრცესთან. ერთი და იგივე იდენტიფიკატორი შეიძლება დამოუკიდებლად განისაზღვროს მრავალ სივრცეში. ამრიგად, ერთ სახელთა სივრცეში განსაზღვრულ იდენტიფიკატორთან ასოცირებულ მნიშვნელობას შეიძლება (ან შეიძლება არ ჰქონდეს) იგივე (ან უფრო სწორად განსხვავებული) მნიშვნელობა, რაც იგივე იდენტიფიკატორს, რომელიც განსაზღვრულია სხვა სახელთა სივრცეში. სახელთა სივრცის მცოდნე ენები განსაზღვრავენ წესებს, რომლებიც მიუთითებენ რომელ სახელთა სივრცეს ეკუთვნის იდენტიფიკატორი (ანუ მისი განმარტება).wiki

ყველაფერი გასაგებია? სინამდვილეში მარტივია. 5.3 ვერსიამდე php-ში მხოლოდ ორი სივრცე იყო - გლობალური (რომელშიც თქვენი მთავარი კოდი იყო შესრულებული) და ლოკალური (რომელშიც იყო განსაზღვრული ფუნქციის ცვლადები).

5.3 ვერსიის შემდეგ ყველაფერი შეიცვალა. ახლა თქვენ შეგიძლიათ განსაზღვროთ თქვენი სახელების სივრცე, რომელშიც იარსებებს თქვენი კლასები, მეთოდები და ა.შ.


იმედია ცოტა უფრო ნათელი გახდა.

მე კონკრეტულად იგივე დავასახელე კლასები. ვინაიდან ისინი განსაზღვრულია სხვადასხვა სივრცეში, ისინი ორი განსხვავებული კლასია, მიუხედავად ერთი და იგივე სახელებისა. მთავარი სკრიპტი კვლავ ფუნქციონირებს გლობალურ სივრცეში, აქ არაფერი შეცვლილა და მასში კლასები და ფუნქციები ჯერ კიდევ შეიძლება განისაზღვროს. მაშინ რისთვის არის სივრცეები? უპირველეს ყოვლისა, დარწმუნდით, რომ როდესაც თქვენ აერთიანებთ ფაილს რაიმე ჩარჩოს ან ბიბლიოთეკაში, თქვენი კლასები არ გადალახავს ჩარჩოს კლასებს ან პირიქით.

იმისათვის, რომ გამოიყენოთ კლასები, რომლებიც განსაზღვრულია თქვენს სახელთა სივრცეში, თქვენ უნდა შემოიტანოთ თქვენს მიერ განსაზღვრული სივრცე გლობალურ სივრცეში სწორ ადგილას (მე ჩვეულებრივ მირჩევნია ამის გაკეთება ფაილის დასაწყისში, ამისათვის გამოიყენეთ საკვანძო სიტყვა).

ყურადღება:რატომღაც php არ იძლევა საკვანძო სიტყვის გამოყენებას გამოყენებამდგომარეობაში ბლოკები და მარყუჟები

ავიღოთ მაგალითი სურათებიდან და განვახორციელოთ კოდით:

ყურადღება:სახელთა სივრცის საკვანძო სიტყვა უნდა განთავსდეს ფაილის დასაწყისშივე, ამის შემდეგ
ფაილი A.php
B.php ფაილი
შესაძლებელია ალტერნატიული სინტაქსი:
რეკომენდებულია თითოეული სახელების სივრცის ცალკე ფაილში გამოცხადება. მიუხედავად იმისა, რომ ეს შესაძლებელია ერთში, მკაცრად არ არის რეკომენდებული!
ახლა გადავიდეთ მესამე ფაილზე, რომელშიც ჩვენი მთავარი სკრიპტი იმუშავებს
index.php
როგორც ჩანს, ეს უპირატესობაა, მხოლოდ მეტი კოდია დამატებული, მაგრამ ეს მთლად ასე არ არის, ცოტა შემდგომ მე მივცემ ავტოჩატვირთვის კლასის მაგალითს, რომლითაც კლასებთან ფაილების დამაკავშირებელი ხაზები ზედმეტი იქნება.
ახლა მოდით გადავხედოთ ჩვენს კლასებს.

ყურადღება:მასშტაბის გარჩევადობის ოპერატორის (::) გამოყენებით php სახელთა სივრცეებში დაუშვებელია! ერთადერთი, რისთვისაც ის შესაფერისია არის სტატიკური კლასის მეთოდებსა და მუდმივებზე წვდომა. თავიდან მათ სურდათ მისი გამოყენება სახელთა სივრცისთვის, მაგრამ შემდეგ გადაწყვიტეს უარი თქვან პრობლემების გამო. მაშასადამე, A::A::say(); არასწორია და გამოიწვევს შეცდომას.

სახელთა სივრცეებისთვის თქვენ უნდა გამოიყენოთ უკუღმა დახაზვის სიმბოლო "\"

ყურადღება:გაუგებრობების თავიდან ასაცილებლად, აუცილებელია ამ სიმბოლოს გაქცევა სტრიქონებში გამოყენებისას: "\\"

სახელთა სივრცეები შეიძლება იყოს ჩადებული ერთმანეთში, მოდით დავამატოთ ჩვენს A.php ფაილს:
და ინდექსში ჩავწერთ შემდეგს:

მნიშვნელოვანი პუნქტია იმპორტირებული ფართებისთვის მეტსახელების გამოყენება. შეგიძლიათ დაწეროთ A\subA::say(); დამეთანხმებით, რომ ძნელია ყოველ ჯერზე სივრცის სრული ბილიკების დაწერა ამის თავიდან ასაცილებლად, შემოღებულ იქნა მეტსახელები. კომპილაციისას მოხდება შემდეგი: მეტსახელის sub-ის ნაცვლად შეიცვლება A\subA, ამიტომ მივიღებთ გამოძახებას A\subA::say();

რა ხდება მაშინ გლობალურ სივრცეში განსაზღვრული ფუნქციების გამოძახებისას? PHP ჯერ ეძებს ფუნქციას იმ სივრცეში, სადაც ამჟამად მუშაობთ და თუ ვერ პოულობს, გადადის გლობალურ ასპექტში. იმისათვის, რომ დაუყოვნებლივ მიუთითოთ, რომ იყენებთ გლობალურ ფუნქციას, წინ უნდა უძღოდეთ მას უკანა ხაზით.

იმისათვის, რომ თავიდან ავიცილოთ პრობლემები კლასების ავტომატური ჩატვირთვასთან სივრცეებიდან, ფაილური სისტემა უნდა იყოს ორგანიზებული სივრცეების ორგანიზების მსგავსად. მაგალითად, ჩვენ გვაქვს root საქაღალდის კლასები, სადაც შეინახება ჩვენი კლასები, შემდეგ ჩვენი სივრცეები შეიძლება ორგანიზებული იყოს შემდეგნაირად.
კლასები\A\A.php
classes\A\sub\A.php (ქვესივრცე განთავსდება ცალკე ფაილში)
კლასები\B\B.php

PHP-ს აქვს ჯადოსნური მუდმივი __NAMESPACE__, რომელიც შეიცავს მიმდინარე სივრცის სახელს.

ახლა კი ავტომატური ჩატვირთვის შესახებ.

ქვემოთ მოყვანილი კლასი ჩემი არ არის, უბრალოდ გავამუშავე და ცოტა გავაუმჯობესე, აქედან აღებული.

ყურადღება:იმისათვის, რომ თქვენი კლასები ჩაიტვირთოს, კლასის სახელი უნდა შეესაბამებოდეს ფაილის სახელს!

" .$ფაილი." in " .$filepath)); if (file_exists($filepath)) (if(Autoloader::debug) Autoloader::StPutFile(("დაკავშირებული" .$filepath)); $flag = FALSE; require_once($filepath); break ) Autoloader::recursive_autoload($file, $path2, &$flag ) ) closeir($handle ) private static ფუნქცია StPutFile($data) ($dir = $_SERVER["DOCUMENT_ROOT"] ); Log/Log.html"; $file = fopen($dir, "a"); flock($file, LOCK_EX); fwrite($file, ("║" .$data ."=>" .date(" d.m.Y H:i:s") ."
║
" .PHP_EOL)); flock ($file, LOCK_UN); fclose ($file); ) ) \spl_autoload_register("yourNameSpace\Autoloader::autoload"); )
თუ გადახედავთ იმ კლასების სახელებს, რომლებიც შემოდის ჩატვირთვისთვის, ნახავთ, რომ თითოეულ კლასს წინ უძღვის პრეფიქსი სახელთა სივრციდან, რომელიც მითითებულია გამოყენებაში. ამიტომ გირჩევთ გამოიყენოთ ფაილების ადგილმდებარეობა სახელთა სივრცის მსგავს კატალოგებში, რაც აჩქარებს ძიებას ერთ ან ორ გამეორებამდე.

ახლა ჩვენი ინდექსი შეიძლება დაიწეროს ასე:
ახლა ყველა კლასი და ინტერფეისი, რომელსაც გამოიყენებთ, ავტომატურად იტვირთება.

ენის ზოგიერთი დინამიური შესაძლებლობების საჩვენებლად სივრცეებით, მოდით გამოვაცხადოთ სხვა კლასი:
test.php

ინდექსი.php
sayName ("ტესტი"); //ან შეგიძლიათ გააკეთოთ ეს ტესტი\sayName("test2"); //ან ასე $obj::sayName("ტესტი"); //ან შეგიძლიათ გააკეთოთ ეს ტესტი::sayName("test2");

იმედი მაქვს, რომ ჩემი სტატია ვინმესთვის სასარგებლო იქნება.

ცვლადი განსაზღვრავს მნიშვნელობას, მაგრამ შეიძლება იყოს მითითება სხვა ცვლადზე და ჰქონდეს თავისი მნიშვნელობა. ალგორითმის შესრულებისას ცვლადი ჩვეულებრივ იღებს ბევრ განსხვავებულ მნიშვნელობას. მუდმივი ინახავს მხოლოდ ერთ მნიშვნელობას. ობიექტი არაპროგნოზირებადია: მას აქვს სტრუქტურა, შინაარსი და მრავალი მახასიათებელი.

სახელთა სივრცე არის დეველოპერის მიერ შექმნილი ცვლადების, მუდმივების, ობიექტების, ფუნქციების და სხვა კონსტრუქციების კოლექცია, რომელთა მითითებაც შესაძლებელია ამ სახელთა სივრცის სახელით.

სახელები: მონაცემთა აღწერის სფერო და ალგორითმები

ელემენტების სახელები (ცვლადები, მუდმივები, ობიექტები, ფუნქციები და სხვა დეველოპერის კონსტრუქტები) არასოდეს იკვეთება. PHP ნებისმიერი სახელის შესატყვისს განმარტავს, როგორც სერიოზულ შეცდომას და იმ შემთხვევებში, როდესაც მას არ შეუძლია პრობლემის ნათლად იდენტიფიცირება, დეველოპერი იღებს კოდს, რომელიც არ მუშაობს ისე, როგორც დაგეგმილი იყო, ან ბრაუზერში თეთრ ველს.

ყველა მონაცემის ყველა სახელი უნდა იყოს უნიკალური, რადგან სივრცე გლობალურია. ობიექტებისა და ფუნქციების სახელები ასევე არ უნდა განმეორდეს, მაგრამ გლობალური ხილვადობის ფარგლები წყდება ობიექტებისა და ფუნქციების მეთოდურ ორგანოებში. მას აქვს საკუთარი ლოკალური სახელების სივრცე და არაფერი გიშლით ხელს, დაარქვათ რაიმე შინაგანად ისე, როგორც გარედან არის მითითებული.

ზემოთ მოყვანილი მაგალითი კლასიკურია, თუ ყურადღებას არ მიაქცევთ სახელთა სივრცის საკვანძო სიტყვას: ყველაფერი ისეა, როგორც ყოველთვის. მეორე მოიცავს ნამუშევრებს. NameSpaceTwo\ პრეფიქსი ფუნქციის სახელების წინ მიუთითებს რომელი ჩასმული კოდიდან არის აღებული.

თუ გლობალურ საკვანძო სიტყვას და ოპერაციას მოვაშორებთ პირველი ფუნქციიდან $iExt = 1; გადავიდეთ ზემოთ მოცემულ ხაზში, მაშინ არც პირველმა და არც მეორე ფუნქციამ არ იცის ცვლადის 100 მნიშვნელობის შესახებ.

სახელთა სივრცეები: აღწერის მრავალი სფერო

ნაჩვენებ მაგალითს აქვს გაზიარებული ფაილი, რომელიც იყენებს ორ ჩანართს. თითოეულ ჩანართს აქვს იგივე scCheckName() ფუნქცია. რომელი აირჩიოს, გადაწყვეტს პროგრამისტი იმ სივრცის დასახელების გამოყენებით, რომელიც შესაბამისია საჭირო დროს კოდის სწორ ადგილას.

ის ფაქტი, რომ ერთი და იგივე სახელი არის საერთო კოდში (ჩანართების გაერთიანების შემდეგ) არ იწვევს შეცდომას იმ მარტივი მიზეზის გამო, რომ თითოეული ჩასმული ფაილი მონიშნულია თავისი უნიკალური სახელით.

პირველ ფაილში ყველაფერი, რაც მასში იქნება აღწერილი, ასოცირდება სახელთან NameSpaceOne. მეორე ფაილში ყველა აღწერა ასოცირდება სახელთან NameSpaceTwo.

ორივე ფაილში დაშვებულია სახელების ნებისმიერი დუბლირება, მაგრამ თითოეულ მათგანში ნებისმიერი ელემენტის სახელი (ცვლადი, მუდმივი, ობიექტი, ფუნქცია) უნდა იყოს უნიკალური.

ამ მაგალითში, scCheckName() ფუნქციის გამოძახებაში სახელთა სივრცის სახელის შეცვლამ ხელი შეუშალა მეორე სახელთა სივრცის $iExt ცვლადის შეცვლას. ამიტომ მაგალითში სიტყვა „შეცვლილი“ სპეციალურად არის ხაზგასმული - ცვლილება რეალურად არ მომხდარა. ცვლადის მნიშვნელობა იგივე რჩება.

ტესტირება და მრავალჯერადი დიზაინი

ეს მარტივი მაგალითები აჩვენებს, რომ თქვენ შეგიძლიათ მარტივად გაამარტივოთ რთული პროექტების განვითარება, გაზარდოთ ეფექტურობა, პროდუქტიულობა და დააჩქაროთ მუშაობა. რა თქმა უნდა, მაშინვე გაჩნდა პირველი იდეები სახელთა სივრცის გამოყენების შესახებ:

• სკრიპტების უსაფრთხო ტესტირება - „სამუშაო“ სივრცეების სატესტო ანალოგებით ჩანაცვლებით;
• უსაფრთხო დიზაინი დეველოპერების დიდი გუნდების მიერ - მათთვის ელემენტების აღწერისთვის „ინდივიდუალური“ სივრცეების მიწოდებით.

სინამდვილეში, სახელთა სივრცე ბევრად უფრო მნიშვნელოვანია. PHP ენა, სახელთა სივრცე და აღწერის თითოეული ელემენტი (ცვლადი, მუდმივი, ობიექტი...) დიდი ხანია აძლევს დეველოპერს სინტაქსისა და სემანტიკის დამოუკიდებლად მანიპულირების შესაძლებლობას.

ენობრივი კონსტრუქციები და თანამედროვე პროგრამირების ზოგადი წესი: „გაიგეს“ - შესრულებულია - არსებობს წინააღმდეგობა - „თეთრი ეკრანი“ არანაირ გავლენას არ ახდენს პროფესიონალ დეველოპერზე.

ბევრმა პროგრამისტმა არც კი იცის სად მოძებნოს PHP შეცდომის შეტყობინება, როდესაც ბრაუზერში არაფერია (ცარიელი თეთრი ყუთი). მისი განვითარების გარკვეულ ეტაპზე პროგრამისტი ფიქრობს PHP სინტაქსისა და სემანტიკაში, ავტომატურად „მუშაობს“ და შედეგი: საკუთარი სინტაქსი და საკუთარი სემანტიკა, ნებადართულის ფარგლებში.

თეთრი ეკრანი არის პროფესიონალი პროგრამისტის დაუყოვნებელი ცალსახა რეაქცია და შეცდომა აღმოიფხვრება. რატომ კარგავთ დროს გამართვას და შეცდომების ჟურნალის ნახვას?

ობიექტები, მასივები და სახელების სივრცეები

შეიძლება ითქვას, რომ ცვლადები, მუდმივები და ფუნქციები წარსულის საგანია, მაგრამ ისინი გამოიყენება ობიექტების დიზაინში. კარგი კოდია, როდესაც ალგორითმი წარმოდგენილია ურთიერთქმედების ობიექტებით და არა სწორი კონსტრუქციების თანმიმდევრობით.

თუ იყენებთ ობიექტების მასივებს, მანიპულირებთ სტეკის იდეით და მასივის ბოლო (პირველი) ელემენტით, შეგიძლიათ მიიღოთ დინამიკა: თავად ობიექტები „წყვეტენ“ როგორ უნდა იმუშაოს საიტის ფუნქციონირება არსებული სიტუაციიდან გამომდინარე. .

PHP-ში სახელთა სივრცე არის სპეციალური სახის ცვლადი, რომელიც წარმოდგენილია თავისი უნიკალური სახელით, ხშირად რთული. კოდში გამოყენებულია სახელთა სივრცის სახელი. თუ ეს არის სტრიქონი, მაშინ შეგიძლიათ შეცვალოთ ერთი სივრცე მეორეთი სკრიპტის შესრულების დროს.

თუ PHP იყენებს სახელთა სივრცის სახელებს, როგორც ცვლადის მნიშვნელობებს, მაშინ ეს კიდევ უფრო სემანტიკურად დატვირთული სინტაქსია, უფრო ძლიერი ვიდრე ობიექტების მასივები.

ობიექტი არის სტრუქტურა და შინაარსი, რომელიც ხასიათდება ერთიანობით. სახელთა სივრცე არის ობიექტების, ელემენტების და მათ შორის ურთიერთობების ერთობლიობა.

შეუძლებელია ექსპერიმენტების ჩატარება გაშვებულ სისტემაზე, მაგრამ სახელთა სივრცის წყალობით, PHP იძლევა შესაძლებლობას მოახდინოს რეალური გაშვებული სისტემის სიმულაცია განსხვავებულ სივრცეში მიზნებისთვის:

• შემდგომი განვითარება;
• ტესტირება;
• მოვლა და ა.შ.

თუ PHP-ის დეველოპერების მიერ შემოთავაზებული სინტაქსის აბსტრაციას შევუდგებით და სახელთა სივრცეებს ​​წარმოვიდგენთ, როგორც ობიექტების გლობალურ კომპლექსურ სისტემებს, მაშინ შესაძლებლობების ჰორიზონტები მრავალჯერ ფართოვდება.

სახელთა სივრცის სინტაქსი და გამოყენება

PHP იღებს მხოლოდ სიტყვას სახელთა სივრცეში კოდის პირველ სტრიქონში თითოეულ ფაილში. ყველა აღწერილობა უნდა დაიცვას მხოლოდ მას. სინტაქსი მოიცავს მხოლოდ სახელს, რომელიც აღინიშნება სახელის ჩვეულებრივი გაგებით.

მნიშვნელოვანია გამოიყენოთ სწორი სიტყვები, რომლებიც გადმოსცემენ მნიშვნელობას. უმჯობესია, როდესაც სახელი გრძელია, მაგრამ შეიცავს რაღაცას, რაც ნათლად აცნობიერებს რა სივრცეზე ვსაუბრობთ, რას აკეთებს, რას აღწერს, რას იღებს ან რისთვის შეიქმნა.

სივრცეები შეიძლება განუსაზღვრელი ვადით იყოს ბუდებული, მაგრამ ეს არ უნდა იყოს ზედმეტი. სახელი უნდა იყოს მკაფიო, ბუდე უნდა იყოს გამართლებული და სივრცის სახელების თანმიმდევრობას უნდა ჰქონდეს ლოგიკა.

გამოყენებისა და სახელების სივრცის აპლიკაციებში, PHP იძლევა კომპლექსურ კოდირებას, მაგრამ შეძლებისდაგვარად, უმჯობესია შეასრულოთ მარტივი ვარიანტი.

ზოგადი წესია: სახელთა სივრცე არის აღწერა და ეს არის ერთი ფაილი, გამოყენება არის სივრცის იმპორტი გამოყენების სკრიპტში და მასზე მეტსახელის (მოკლე ბმული) მინიჭება.

კლასების (ობიექტების) ავტომატური ჩატვირთვის მარტივი მაგალითი

ამოცანა შეიცავს ობიექტს სტრიქონების მანიპულირებისთვის, გვერდის ელემენტების სტილებით (CSS აღწერილობები), თარიღის ობიექტს, ფაილური სისტემის ობიექტს და მონაცემთა ბაზის ობიექტს. განხორციელების მიზანია ამ ხუთი პოზიციისთვის მარტივი ინტერფეისების შექმნა, რათა გამოიყენოს საჭირო შესაძლებლობები მხოლოდ ამ ობიექტების მეთოდებით.

დაუშვებელია ენობრივი ფუნქციებისა და კონსტრუქციების პირდაპირი გამოყენება. ეს ამოცანა იყენებს PHP კლასის ავტომატურ ჩატვირთვას. სახელთა სივრცე განიხილება, როგორც ფაილური სისტემის კონკრეტულ ადგილას მდებარე ობიექტების კოლექცია. როგორც წესი, ყველა ობიექტი განლაგებულია ფაილურ სისტემაში მათი მნიშვნელობის მიხედვით, საქაღალდეებში და ფაილებში კონკრეტული სახელით.

მარცხნივ კოდი მიუთითებს საჭირო ხუთი ობიექტის შექმნაზე, მაგრამ ზუსტად სად მდებარეობს ისინი არ არის მითითებული. კოდი მარჯვნივ გვიჩვენებს ავტოჩამტვირთველის (მთავარი სკრიპტის) ტექსტს, რომელიც კლასების (ობიექტების) ჩატვირთვისას ავტომატურად ანაცვლებს საჭირო გზას ობიექტის ადგილმდებარეობისა და .php ფაილის გაფართოებისკენ.

მრავალი სახელთა სივრცის მაგალითი

PhpOffice/PhpWord ბიბლიოთეკა კარგი მაგალითია მრავალი სახელთა სივრცის რთული იერარქიის გამოყენებისათვის. ელემენტების საქაღალდე შეიცავს ელემენტების თითქმის მთელ დიაპაზონს, რომელიც ხელმისაწვდომია *.docx დოკუმენტის (MS Word) შექმნისას, სხვა საქაღალდეები შეიცავს ელემენტებთან, აბზაცებთან და ცხრილებთან მუშაობის აუცილებელ ინსტრუმენტებს.

სინამდვილეში, ბიბლიოთეკა განთავსდა პროექტის საქაღალდეში იმ მიზეზით, რომ PhpOffice / PhpWord ფუნქციონალური სივრცის დამატება სჭირდებოდა კონკრეტული ხელსაწყოებით და საბოლოოდ შექმნათ მსგავსი პროდუქტის საკუთარი ვერსია.

იტვირთება სხვადასხვა სახელების სივრცის მრავალი კლასი

PHP სახელთა სივრცის ავტომატური დატვირთვის გამოყენება, როდესაც საჭიროა მრავალი კლასის ჩატვირთვა, ხოლო ობიექტების განვითარებული სისტემის იერარქია საკმაოდ რთული და ძნელი წარმოსადგენია, იწვევს ხისტი სტრუქტურების შექმნის აუცილებლობას.

დეველოპერის ორიენტაცია (რომელიც იყენებს პროდუქტს მუშაობის გასაგრძელებლად) შესაძლებელია მხოლოდ სემანტიკის კონტექსტში (პროექტის გაგება), რომელიც წარმოდგენილია სიტყვების შესაბამისი კომბინაციებით, რომლებიც ასახავს ობიექტების რეალურ მნიშვნელობას და ურთიერთობებს.

ბიბლიოთეკის ინდივიდუალურ პროექტში გამოყენების აუცილებლობა იწვევს პრობლემის გადაჭრას, თუ როგორ გავაერთიანოთ დეველოპერი და PhpOffice / PhpWord ავტორის სახელების სივრცეები. საუკეთესო გზაა ამ პროდუქტის (მისი სივრცეები და ობიექტები) განთავსება საკუთარ საპროექტო სივრცეში.

მნიშვნელოვანია აღინიშნოს, რომ შეუძლებელი იქნება ამ პროდუქტის სახელთა სივრცის შეცვლის გარეშე მისი აბსტრაქტული ელემენტებისა და კლასის დატვირთვის დონეზე. ეს მიუთითებს იმაზე, რომ PHP სახელთა სივრცეში შიდა სახელთა სივრცის გამოყენება შეიძლება არ იყოს საკმარისად აბსტრაქტული და უნივერსალური.

ფაილური სისტემა და სივრცეების ლოკალიზაცია

არსებითად, სახელთა სივრცე არის ფაილური სისტემის გზის „ნახაზი“ სასურველ ობიექტამდე. ფაილის სახელების გამოყენება ობიექტების სახელებად ბუნებრივი და ნაცნობია. საქაღალდის სახელების გამოყენება სახელთა სივრცის დასახელებისთვის ობიექტურია.

ინფორმაციის "ხის" ორგანიზაცია საკმაოდ შრომატევადია გამოსაყენებლად და ართულებს განვითარებას, მაგრამ ეს არის ბუნებრივი წარმოდგენა ობიექტების სისტემებისთვის.

პრობლემა ის არის, რომ განვითარების ეტაპი წარმოდგენილია სპეციფიკური კოდის რედაქტორით, რომელიც აერთიანებს როგორც საქაღალდეების ხილულ წარმოდგენას, ასევე კონკრეტული საქაღალდის შიგთავსს, მაგრამ ჯერ არ არსებობს რედაქტორი, რომელიც უზრუნველყოფს ბოლომდე გადაადგილებას ობიექტების და მეშვეობით. საქაღალდეები.

აბსტრაქციისა და უნივერსალურობის პრობლემა

მიღებულია დეველოპერის ცნობიერებისა და მიზნის მიერ რეალურად:

• უზრუნველყოფს აბსტრაქციას და ინფორმაციის მანიპულირების უნარს მისი რეალური სემანტიკის მიხედვით;
• სახელთა სივრცეები ასახავს სკრიპტების, ობიექტების პოზიციას და ნაწილობრივ პროექტის მნიშვნელობას ფაილურ სისტემაში

სინამდვილეში, OOP აბსტრაქციის მიერ ობიექტების სახელებთან (ფაილებთან) დაკავშირებით და ფაილურ სისტემაზე (საქაღალდეებზე) გადაფარვით სახელთა სივრცის ადეკვატური ფორმირებით (ბილიკები + სახელები), შეგიძლიათ აკონტროლოთ სახელთა სივრცის ფორმირება სკრიპტის შესრულების დროს.

პროგრამირებამ უკვე შეიძინა განვითარების მძლავრი დინამიკა, მაგრამ თუ გადავიტანთ განვითარების ეტაპის პროცესს და დატვირთვას ტექსტის რედაქტორიდან (რომელშიც იქმნება სკრიპტები და მოთავსებულია საქაღალდეების ხეებში) კოდის გენერირების იდეაზე. საშუალებას აძლევს საკუთარ თავს გაუმჯობესდეს და განთავსდეს ფაილურ სისტემაში სწორ ადგილას - პროგრამირება ახალ სიმაღლეებზე აიწევს.