Rumah > pembangunan bahagian belakang > tutorial php > Pertempuran Autoloaders: PSR-0 vs PSR-4

Pertempuran Autoloaders: PSR-0 vs PSR-4

Christopher Nolan
Lepaskan: 2025-02-23 08:45:11
asal
199 orang telah melayarinya

3

Takeaways Key Battle of the Autoloaders: PSR-0 vs. PSR-4

PSR-0 dan PSR-4 adalah piawaian autoloading dalam PHP, dengan laluan yang menentukan PSR-0 berdasarkan ruang nama kelas dan membolehkan garis bawah dalam nama kelas, manakala PSR-4 bertujuan untuk memudahkan struktur folder dan mengeluarkan sisa-sisa PSR- 0. Pertempuran Autoloaders: PSR-0 vs PSR-4

PSR-4, yang dirujuk sebagai autoloading berorientasikan pakej, membolehkan pakej bersih tetapi lebih rumit untuk dilaksanakan. Ia juga memastikan bahawa autoloader tidak boleh membuang pengecualian atau menimbulkan kesilapan, mengekalkan keserasian dengan pelbagai Autoloaders.

kedua-dua PSR-0 dan PSR-4 mempunyai kebaikan dan keburukan mereka: PSR-4 membolehkan struktur folder yang lebih mudah tetapi tidak menunjukkan laluan tepat kelas dari nama yang berkelayakan sepenuhnya, sementara PSR-0 boleh menjadi huru-hara tetapi Menyokong pemaju menggunakan konvensyen penamaan dan bantuan yang lebih tua dalam mencari kelas dari namanya.
  • Jika anda telah melepasi peringkat pemula dalam latihan PHP anda, anda telah mendengar PSR-0-standard autoloading yang mentakrifkan cara untuk memasukkan kelas PHP secara automatik dalam kod anda tanpa perlu menggunakan kenyataan seperti yang diperlukan dan termasuk.
  • psr-0
  • PSR-0 melihat ruang nama kelas dan membezakan lokasinya pada cakera keras dari sedikit maklumat itu. Sebagai contoh, kelas ZendmailMessage akan membawa kepada /path/to/project/lib/vendor/zend/mail/message.php.

PSR-0 juga menyokong garis bawah dalam nama kelas sebagai alternatif, untuk membuat peralihan dari 5.2 dan lebih awal lebih mudah. Zend_mail_message juga akan membawa kepada /path/to/project/lib/vendor/zend/mail/message.php.

komposer

Apabila komposer muncul dan mengambil dunia pengurusan pakej PHP dengan ribut, perkara berubah. Oleh kerana beberapa peraturannya, folder sering diduplikasi dan menjadi terlalu mendalam apabila melihat pemasangan kelas PSR-0 melalui komposer. Sebagai contoh, beberapa struktur folder berakhir seperti ini:

ini huru -hara yang terbaik, kerana:

direktori "SRC" dan "Ujian" perlu memasukkan nama direktori vendor dan pakej. Ini adalah artifak pematuhan PSR-0.

vendor/
    vendor_name/
        package_name/
            src/
                Vendor_Name/
                    Package_Name/
                        ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                Vendor_Name/
                    Package_Name/
                        ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest
Salin selepas log masuk
Salin selepas log masuk
Oleh itu, beberapa php devs yang berkelayakan berkumpul dan mengumpulkan cadangan untuk standard baru: PSR-4.

psr-4

PSR-4 bertujuan untuk melengkapkan dan bekerjasama dengan PSR-0 jika perlu, tidak menggantikannya sepenuhnya. Ia boleh, tetapi tidak perlu. Matlamat utama PSR-4 adalah untuk menghapuskan sisa-sisa PSR-0 dan pra-5.3 hari sepenuhnya, dan membolehkan struktur folder yang lebih ringkas. Dengan PSR-4, pokok folder di atas akan kelihatan seperti ini:

Menaik taraf PSR-0 bukan pilihan

kerana PSR-0 tidak membenarkan laluan syaitan antara mana-mana bahagian nama kelas

Ini sangat penting-ini bermakna bahawa melaksanakan PSR-4, sambil membenarkan pakej yang lebih bersih, akan jauh lebih rumit untuk dilaksanakan. Kami memanggil autoloading berorientasikan pakej PSR-4, kerana ia memihak kepada kebersihan pakej sebelum kesederhanaan.

Pendekatan yang dipilih

Matlamat yang dicadangkan adalah seperti berikut: Pastikan peraturan PSR-0 bahawa semua pakej mesti mengandungi sekurang-kurangnya dua tahap ruang nama (vendor dan pakej), pastikan kombo pakej vendor boleh memetakan ke mana-mana folder, dan membolehkan infix folder antara kombo pakej vendor dan seluruh nama kelas yang berkelayakan.

Ini bermakna kita akan dapat meletakkan kelas kita di mana -mana dalam kod pakej di mana ia masuk akal kepada kita sebagai manusia, dan masih menggunakannya dengan lancar dalam PHP tanpa menulis teknik pemuatan alternatif atau menggunakan pemuatan manual.

Selain itu, draf secara eksplisit menyatakan bahawa autoloader PSR-4 tidak boleh membuang pengecualian atau menimbulkan kesilapan semata-mata kerana autoloader berbilang boleh didaftarkan, dan jika seseorang gagal memuat kelas, yang lain harus diberi peluang untuk berbuat demikian-membuangnya- Kesalahan dan menghentikan aliran memecah keserasian ini. Sekiranya maklumat tambahan mengenai kegagalan diperlukan, seseorang harus menggunakan logger serasi PSR-3 atau cara sewenang-wenangnya.

seperti yang digambarkan dalam fail contoh, menggunakan autoloader PSR-4 untuk memuat kelas dari struktur berikut:

vendor/
    vendor_name/
        package_name/
            src/
                Vendor_Name/
                    Package_Name/
                        ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                Vendor_Name/
                    Package_Name/
                        ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest
Salin selepas log masuk
Salin selepas log masuk

akan kelihatan seperti ini:

vendor/
    vendor_name/
        package_name/
            src/
                ClassName.php       # Vendor_Name\Package_Name\ClassName
            tests/
                ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest
Salin selepas log masuk

di mana memanggil Foobarquxquux baru; akan cuba memuatkan dari direktori berdaftar pertama, sementara Foobarquxquuxtest baru; akan cuba memuatkan dari yang kedua.

Contoh ini juga menggambarkan penggunaan pelbagai folder setiap ruang nama tunggal.

Kesimpulan

Tidak ada peluru perak dalam autoloading. Setiap pendekatan membawa dengan sendirinya beberapa kebaikan dan keburukan-PSR-4 akan membolehkan struktur folder yang lebih mudah, tetapi akan menghalang kita daripada mengetahui jalan yang tepat dari kelas hanya dengan melihat nama yang berkelayakan sepenuhnya. Sebaliknya, PSR-0 adalah huru-hara pada cakera keras, tetapi menyokong pemaju yang terjebak pada masa lalu (pengguna underscore-in-class-name) dan membantu kita membezakan lokasi kelas hanya dengan melihat namanya.

Bagaimana perasaan anda tentang PSR-4? Marilah kita tahu dalam komen di bawah, atau nyatakan pendapat anda dalam salah satu daripada banyak perdebatan.

Sama ada cara-tidak ada keraguan autoloading berorientasikan pakej di sini untuk kekal. Jika tidak diterima secara rasmi sebagai standard, maka adat yang dilaksanakan oleh orang yang memerlukannya. Terserah kepada kami untuk menyertai perbincangan dan memperbaiki tanggapan yang cukup untuk mencapai keadaan formal ini.

Soalan Lazim mengenai PSR-0 dan PSR-4 Autoloading

Apakah perbezaan utama antara PSR-0 dan PSR-4? PSR-0 memerlukan korelasi langsung antara ruang nama dan struktur direktori, yang bermaksud bahawa setiap garis bawah di ruang nama sepadan dengan pemisah direktori. Sebaliknya, PSR-4 membolehkan pendekatan yang lebih fleksibel, di mana sebahagian ruang nama boleh dipetakan ke mana-mana direktori, dan seluruh ruang nama boleh dipetakan ke struktur subdirektori. PSR-4 diperkenalkan apabila PSR-0 sudah ada? Hubungan ketat PSR-0 antara ruang nama dan struktur direktori membawa kepada direktori yang sangat bersarang, yang tidak selalu praktikal atau cekap. PSR-4 memberikan pendekatan yang lebih fleksibel, membolehkan pemaju memetakan ruang nama ke mana-mana direktori, mengurangkan keperluan untuk bersarang direktori yang mendalam. > Ya, mungkin menggunakan PSR-0 dan PSR-4 dalam projek yang sama. Walau bagaimanapun, penting untuk diperhatikan bahawa mereka tidak boleh digunakan untuk mengendalikan kelas yang sama. Menggunakan kedua-dua piawaian boleh bermanfaat dalam projek besar di mana beberapa kod warisan mengikuti piawaian PSR-0, manakala kod yang lebih baru mengikuti piawaian PSR-4.

PSR-4 bertambah baik pada PSR-0 dengan memberikan pendekatan yang lebih fleksibel untuk autoloading. Ia membolehkan pemaju memetakan sebahagian ruang nama ke mana -mana direktori, mengurangkan keperluan untuk bersarang direktori yang mendalam. Ini menjadikannya lebih mudah untuk mengurus dan menavigasi struktur direktori projek.

Adakah PSR-0 ditutup? Ini bermakna bahawa walaupun ia masih berfungsi, tidak disyorkan untuk digunakan dalam projek baru. PSR-4 adalah standard yang disyorkan untuk autoloading dalam php.

Bagaimana autoloading berfungsi dalam psr-4?

. Selebihnya ruang nama kemudian dipetakan ke struktur subdirektori. Ini membolehkan pendekatan yang lebih fleksibel dan cekap untuk autoload. Perlu bersarang direktori yang mendalam, dan kecekapan yang lebih baik. Ia juga merupakan standard yang disyorkan untuk autoloading di PHP, menjadikannya pilihan yang baik untuk projek baru. Kepada PSR-4 melibatkan perubahan ruang nama dan direktori yang dipetakan. Dalam PSR-4, sebahagian daripada ruang nama boleh dipetakan ke mana-mana direktori, dan seluruh ruang nama boleh dipetakan ke struktur subdirektori. Ini mungkin memerlukan penstrukturan semula struktur direktori projek anda.

Bolehkah saya menggunakan PSR-4 dalam versi PHP yang lebih lama? Sekiranya anda menggunakan versi PHP yang lebih lama, anda perlu menaik taraf untuk menggunakan PSR-4. PHP mungkin terus berkembang, dengan piawaian dan amalan baru yang diperkenalkan sebagai bahasa dan ekosistemnya berkembang. Walau bagaimanapun, untuk masa hadapan, PSR-4 adalah standard yang disyorkan untuk autoloading dalam php.

Atas ialah kandungan terperinci Pertempuran Autoloaders: PSR-0 vs PSR-4. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

Kenyataan Laman Web ini
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Artikel terbaru oleh pengarang
Tutorial Popular
Lagi>
Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan