Rekayasa Internal Kerangka RAD... sebagai Pengembang PHP dengan Nooku

Setiap orang memiliki seperangkat alat mereka sendiri. Sebagai pengembang PHP, salah satu favorit saya adalah kerangka Pengembangan Aplikasi Cepat yang disebut “Nooku”. Dalam kata-kata grup pengembangan: "Nooku lebih merupakan alat pengembangan web daripada kerangka kerja".

Jika Anda tidak terbiasa dengan itu, lihatlah. Ini adalah proyek sumber terbuka yang banyak menggunakan pola desain yang diterima industri untuk menghasilkan aplikasi dengan komponen tinggi yang mudah dikembangkan dan digunakan kembali (awalnya dibuat oleh salah satu pengembang utama Joomla!). Di luar kotak, Nooku memberi Anda banyak alat pengembangan aplikasi cepat untuk membantu menyelesaikan proyek lebih cepat. Contoh kecil, tapi kuat:

• Implementasi default MVC di mana yang perlu Anda lakukan hanyalah menulis tata letak (inilah yang membuat saya ketagihan)
• Ketersediaan HMVC segera
• Dukungan untuk format output yang berbeda seperti JSON dan XML untuk semua data Anda (yaitu, mengekspos API Anda dalam hitungan menit)
• Implementasi administratif dan front-end default

Inti dari Nooku adalah prinsip desain "Komposisi atas Warisan" (sebenarnya, ini adalah konsep pertama di halaman pengantar Nooku. Dalam satu baris: Anda harus bertujuan untuk menyusun (atau menambahkan) fungsionalitas beberapa objek untuk membuat beberapa semacam objek komposit, daripada mengandalkan subclassing.

Prinsip ini memungkinkan Anda menulis lebih sedikit kode dan sering kali mengarah ke beberapa solusi yang cukup elegan. Jadi bagaimana sebenarnya itu dipromosikan? Nah, di tingkat kode, contoh terbaik datang melalui penggunaan Mixin dan Resource/Service Identifier. Mari lihat.

Campuran

Sebelum PHP 5.4, bahasa tersebut tidak memiliki konsep Traits . Ini adalah struktur seperti kelas yang, ketika 'digunakan' oleh suatu objek, menyediakan beberapa jenis fungsionalitas (mirip dengan Multiple Inheritance). Nooku telah memecahkan masalah ini selama bertahun-tahun (sejak PHP 5.2) dengan Mixin .

Mixin tidak hanya memungkinkan Anda membuat objek bersama-sama, tetapi juga menambahkan metode setiap objek campuran ke antarmuka objek komposit. Objek yang menggunakan mixin tampaknya 'mewarisi' metode campuran dalam objek.

 /** * Mixin an object * * When using mixin(), the calling object inherits the methods of the mixed * in objects, in a LIFO order. * * @param KMixinInterface $object An object that implements KMinxInterface * @return KObject */ public function mixin(KMixinInterface $object) { $methods = $object->getMixableMethods($this); foreach($methods as $method) { $this->_mixed_methods[$method] = $object; } // Set the mixer $object->setMixer($this); return $this; }

Hampir semua objek di Nooku memiliki kemampuan ini karena mereka memperluas kelas dasar KObject yang mendefinisikan metode mixin .

Kelas utama dalam arsitektur pengontrol Nooku juga diturunkan dari KObject. Kontroler abstrak adalah kelas KControllerAbstract dan dengan inspeksi Anda dapat melihat bahwa itu mengambil keuntungan dari kemampuan Mixing segera. Setiap kali instance kelas ini dibuat, fungsionalitas KMixinCommand dan KMixinBehavior segera ditambahkan ke antarmukanya. Akibatnya, setiap pengontrol di Nooku disusun dengan fungsi manajemen Rantai Perintah dan Perilaku melalui objek masing-masing.

Kembali ke pengontrol Nooku: kelas KMixinBehavior menampung semua bagian untuk memberi KControllerAbstract kemampuan untuk memuat Perilaku tertentu saat runtime. Strategi perilaku adalah kelas yang menggambarkan proses atau logika yang dapat dipisahkan dan digunakan oleh kelas lain (misalnya, dapat diedit, dapat dipesan). KMixinBehavior cukup sederhana dan hanya memiliki empat metode: getBehavior, hasBehavior, addBehavior dan getBehaviors. Dan hanya itu yang kita butuhkan untuk memberikan objek kemampuan untuk menangani dan merangkum berbagai strategi perilaku.

Demikian pula, KMixinCommand hanya memiliki tiga metode: getCommandContext, getCommandChain, setCommandChain. Jika Anda tidak menebaknya, ketiga metode ini memberikan KControllerAbstract kemampuan untuk mengimplementasikan rantai perintah, tetapi memungkinkannya melakukannya saat runtime.

Anda dapat menganggap pencampuran ini sebagai penjumlahan aritmatika sederhana:

Memberi kita antarmuka yang terlihat seperti ini:

Menurut definisi Kelas abstrak dimaksudkan untuk diperluas dan dengan keajaiban pewarisan semua objek yang merupakan anak-anak atau instance dari KControllerAbstract juga mendapatkan kemampuan untuk menambahkan perilaku dan rantai perintah saat runtime.

Terdengar keren. Tapi apa maksud yang sebenarnya? Singkatnya, Nooku menyediakan fungsionalitas komponen; yaitu, Nooku memungkinkan Anda untuk memodulasi fungsionalitas Anda dan menyusun fungsionalitas di seluruh modul saat runtime.

Kedua contoh ini berfungsi untuk menunjukkan komposisi. Mereka juga berfungsi untuk menunjukkan dukungan kerangka kerja Nooku RAD untuk komposisi lebih lanjut pada intinya. Ini adalah keuntungan penting. Metode yang ditambahkan ke KControllerAbstract di atas mendukung "Pola Desain Strategi" dengan memberi pengembang alat untuk merangkum apa yang bervariasi sebelum satu baris kode ditulis. Fakta bahwa metode mixin() adalah bagian dari setiap ekstensi KObject berarti Anda dapat dengan mudah mendefinisikan dan menambahkan antarmuka manajemen perilaku lainnya ke sebagian besar objek saat runtime.

Pengidentifikasi dan Pencari Layanan dan Sumber Daya: Pisahkan Nama Kelas Saya dari Objek Saya

Pengidentifikasi dan Pencari Layanan dan Sumber Daya di Nooku juga memberikan dukungan yang kuat untuk pemisahan masalah.

Sekali lagi, mari kita lihat lagi KObject, tetapi juga KService. Kami dapat memperlakukan sebagian besar hal di Nooku sebagai layanan atau sumber daya, dan dengan demikian memberi contoh dan menginterogasinya dengan cara yang persis sama.

Ketika Anda pergi ke toko kelontong dan membeli produk, pikirkan toko itu sebagai Layanan, yaitu, kumpulan barang yang dapat Anda urutkan ; dan produk sebagai Sumber Daya, yaitu, satu item/logika solusi yang dapat berupa:

• melihat secara khusus ( Baca) (misalnya, melihat sekaleng sup tomat)
• bergerak di sekitar toko ( E dited) (misalnya, memindahkan sup ke lorong produksi)
• ditambahkan ke atau dihapus dari inventaris toko ( A dd dan D elete) (mis., tambahkan jenis sup baru dan singkirkan tomat)

Mengambil contoh ini lebih jauh, bayangkan toko kelontong memiliki departemen waralaba dan Anda ingin berbisnis. Dalam situasi itu, Layanan adalah departemen waralaba dan sumber dayanya adalah toko kelontong yang Anda beli. Ini sangat banyak klasifikasi kontekstual. Secara keseluruhan, ini dikenal sebagai pola tindakan BREAD (Anda akan melihat masing-masing diwakili antara KControllerService dan KControllerResource yang diawali dengan '_action', yaitu _actionRead()).

Model dapat berupa layanan, objek tabel dapat dianggap sebagai layanan, triad MVC tertentu digunakan sebagai sumber daya atau layanan, sedangkan catatan spesifik yang dihasilkan dari interogasi layanan dapat dianggap sebagai sumber daya.

Setiap objek di Nooku adalah komposisi objek yang masing-masing berisi referensi ke seluruh layanan instantiated aplikasi dalam 'wadah layanan' dan metode untuk mengakses layanan yang disebut getService(). Semua yang diperlukan oleh metode KObject::getService() adalah bahwa kita melewati pengenal sumber daya yang valid dan itu akan mengembalikan layanan instantiated yang siap digunakan.

Dalam pengembangan aplikasi cepat PHP, Resource Identifier memberi kita cara yang ampuh untuk memisahkan instantiasi objek dari nama kelasnya, dan dengan demikian memberikan alias untuk identifikasi itu. Ini memiliki implikasi penting pada pemeliharaan aplikasi. Melalui aliasing, pengembang dapat mengubah kelas yang digunakan oleh setiap objek yang dipakai dengan pengenal yang diberikan dengan menambahkan satu baris kode dengan KService::addAlias().

Contoh pengenal sumber daya yang kita kenal adalah URI atau Uniform Resource Identifier:

Ini semua informasi yang diperlukan untuk KService untuk menemukan dan memuat kelas yang sesuai. Potongan-potongan ini cocok dengan penamaan kelas dan konvensi penempatan Nooku yang memberikan prediktabilitas penempatan dan instantiasi. Contoh pengenal dari atas (com://site/user.database.table.user) mencoba memuat file /components/com_user/databases/tables/user.php, yang memiliki nama kelas ComUserDatabaseTableUser. Kebetulan, jika file tidak ada, kerangka kerja akan memberi Anda objek tabel default dan membangunnya berdasarkan penamaan basis data dan konvensi skema id (ini membuat saya ketagihan lagi). Seperti disebutkan sebelumnya, KService juga memungkinkan Anda untuk mengatur alias untuk pengidentifikasi Anda. Menggunakan KService::setAlias('maindbaseadapter','com://admin/default.database.adapter.mysqli') ; memungkinkan kita memuat objek db dengan KService::getService('maindbaseadapter') .

Ini memberi kita decoupling yang kita bicarakan dan memberikan keuntungan yang nyata dalam pemeliharaan dan perluasan aplikasi kita. Kami bebas membuat aplikasi selain 'situs' dan 'admin' jika diperlukan dan melalui pengenal yang dijelaskan di sini dapat menggunakan layanan yang terletak di aplikasi lain dengan mudah untuk membantu solusi kami memenuhi persyaratan mereka. Sekali lagi, ini adalah contoh lain bagaimana Nooku memberikan dukungan kepada pengembang dan tim PHP dan RAD untuk komposisi tidak hanya objek kelas tunggal tetapi seluruh layanan dan aplikasi… gratis.

Menyimpulkan

Dengan komposisi atas warisan pada intinya; komposisi dan struktur cerdas yang sudah ada sebelumnya untuk mendukung amalgam lebih lanjut; dan arsitektur berorientasi layanan gratis dengan pengidentifikasi yang dijelaskan di sini, Nooku menyediakan kerangka kerja RAD yang kuat dengan awal yang signifikan di atas semua alat pengembangan PHP sejawatnya.