Pola Desain XQuery Digunakan Komunitas Berorientasi Objek – desain banyak digunakan dalam komunitas berorientasi objek. Ini adalah solusi yang terbukti, matang, dan dapat digunakan kembali yang membuat pengembangan modul menjadi mudah dengan kopling minimal. Pola desain juga merupakan konstruksi tingkat tinggi yang membantu meningkatkan interaksi antar pengembang. Saat ini, XQuery dan rangkaian spesifikasinya melampaui pengumpulan kueri dan dokumen XML. XQuery semakin banyak digunakan sebagai bahasa pemrograman multi-paradigma. Tujuan artikel ini adalah untuk membenarkan kebutuhan pola desain XQuery menggunakan contoh aplikasi dunia nyata dan untuk mengeksplorasi keberadaan solusi desain umum untuk masalah berulang dalam aplikasi XQuery skala besar.
Pola Desain XQuery Digunakan Komunitas Berorientasi Objek
pengantar
zorba-xquery.com – Selama dekade terakhir, pola desain telah menjadi semakin populer di komunitas berorientasi objek sebagai solusi generik yang dapat digunakan kembali untuk masalah desain perangkat lunak yang lazim. Hampir semua aplikasi, komponen, atau API yang ditulis dalam bahasa berorientasi objek saat ini dibangun menggunakan pola desain. Pola-pola ini meningkatkan pengembangan perangkat lunak di
Perangkat Lunak dan Desain yang Dapat Digunakan Kembali. Pola desain seringkali merupakan kunci untuk enkapsulasi yang lebih baik dan pengurangan kopling. antar komponen perangkat lunak. Akibatnya, perangkat lunak yang mewakili pola desain dapat digunakan kembali, fleksibel, dan dapat diperluas.
Dokumen: Menggunakan nama template dalam dokumentasi perangkat lunak memungkinkan pengembang untuk langsung mengenali/mengingat struktur dan struktur API.
Komunikasi dan Pembelajaran: Pola desain adalah bahasa umum untuk meningkatkan komunikasi antara pengembang perangkat lunak dan analis. Kosakata yang mapan juga memfasilitasi diskusi di antara pengembang dari berbagai bahasa pemrograman.
Pola desain diterima secara luas dan diterapkan di komunitas berorientasi objek, tetapi jarang dikenali di luar komunitas. Misalnya, dalam dunia fungsional tidak dievaluasi pada tingkat pemrograman aplikasi yang kompleks. “Pola Desain Logika Fungsional” [AntoyHanus02FLOPS] mengevaluasi pola desain sebagai bahasa fungsional untuk memecahkan masalah spesifik pada tingkat yang sangat rendah. Saat berdiskusi di level meta. Dari perspektif ini, ketakutan Tom DeMarco tahun 1996 terbukti masuk akal.
“Saya khawatir pengembang perangkat lunak di luar komunitas objek akan mengabaikannya karena pola desain mengklaim hanya tertarik pada perangkat lunak berorientasi objek. Ini akan menjadi canggung. Semua pengembang perangkat lunak menggunakan pola. Pemahaman yang lebih baik tentang abstraksi yang dapat digunakan kembali dalam pekerjaan kami hanya dapat membantu dalam hal ini.”
Baca Juga : Tujuan Umum Zorba – Prosesor XQuery Yang Diimplementasikan
Sebagai bahasa fungsional dan deklaratif, XQuery dikembangkan oleh World Wide Web Consortium sebagai bahasa pemrosesan XML tujuan umum yang cocok untuk berbagai arsitektur dan lingkungan. Awalnya, XQuery terutama digunakan untuk query data XML dari sistem database (misalnya [XQueryInAction]), tetapi secara bertahap menjadi bahasa pemrograman aplikasi yang lengkap. Satu skenario di mana XQuery digunakan sebagai bahasa pemrograman lengkap disebut arsitektur XML ujung ke ujung. Dalam arsitektur ini, XML adalah bentuk utama penyimpanan dan pemrosesan informasi. Informasi ini disimpan di seluruh panggilan program yang berurutan, dan XQuery adalah bahasa utama untuk mengakses informasi ini untuk menemukan, memfilter, mengubah, memperbarui, dan membangun alur kerja aplikasi yang lebih kompleks. Juga di dalam program, XQuery diperkenalkan ke layanan web, entitas web seperti Atom, JSON, pesan HTTP, dan metode otentikasi umum seperti OpenID atau OAuth. Bersama dengan spesifikasi ekstensi XQuery Update [XQUF], XQuery Scripting [XQSE] dan XQuery Full Text [XQFT], XQuery saat ini bekerja di liga yang sama dengan bahasa pemrograman tujuan umum seperti Java, Python atau Ruby, tetapi masih di tepian. Dalam hal ekspresi dan dukungan kelas satu untuk menangani sumber daya web.
Secara keseluruhan, perubahan terkini ini secara pribadi terkait menggunakan pertumbuhan pelaksanaan XQuery yg kompleks [Kaufmann2009]. Salah satu model pelaksanaan semacam itu dikembangkan sang pelanggan perusahaan loka penulis bekerja. Aplikasi ini merupakan pelaksanaan Enterprise Resource Planning (ERP) yg seluruhnya ditulis pada XQuery pada atas Server Aplikasi Web Sausalito [Sausalito2010]. Aplikasi ini terdiri menurut 28.000 baris kode XQuery yg diimplementasikan pada 135 modul XQuery. Dengan mengaudit pelaksanaan ini, kami menemukan tanda-tanda generik pada basis kode & proses pengembangan:
Modul mempunyai kopling yg bertenaga antara satu sama lain. Mereka didasarkan dalam kerja sama kompleks yg mengurangi fungsinya balik pada kerangka kerja atau pelaksanaan lain. Dalam kebanyakan kasus, memperluas atau menyusun modul akan memerlukan pemfaktoran ulang kode yg mengganggu.
Beberapa desain struktural berulang dirujuk memakai kosakata yg berbeda. Meskipun mereka bisa dicermati menjadi identik menurut sudut pandang abstrak. Ini menaikkan penghalang masuk ke basis kode secara signifikan.
Seperti yg dijelaskan pada awal bagian ini, kasus misalnya itu sudah dipecahkan pada komunitas berorientasi objek menggunakan berbagi & menerapkan pola desain. Didorong sang pengamatan ini, kami tetapkan buat mulai memakai pola desain buat mengatasi ketidaksesuaian yg dijelaskan pada atas. Selain memotivasi penggunaan pola desain buat XQuery, donasi makalah ini merupakan buat mengidentifikasi ketidaksesuaian pada pelaksanaan global konkret & menerangkan bagaimana ketidaksesuaian ini bisa diperbaiki menggunakan memakai pola desain. Secara khusus, kami menyajikan empat pola desain & menyebutkan bagaimana masing-masing pola tadi memecahkan satu kasus desain eksklusif pada pelaksanaan model (yg sedang berjalan) kami.
Sisa artikel ini disusun sebagai berikut. Bagian 2 menjelaskan kasus penggunaan untuk contoh kerja. Contoh ini digunakan untuk mendemonstrasikan masalah desain yang ada dalam aplikasi dunia nyata. Di masing-masing dari empat bagian berikut (Bagian 3, 4, 5, 6) kami menyajikan pola desain untuk mengatasi salah satu masalah desain yang diidentifikasi. Bagian 7 menyimpulkan dokumen dan memberikan pandangan tentang pekerjaan di masa depan.
Menjalankan Contoh: Aplikasi AtomPub
Protokol Penerbitan Atom (AtomPub; lihat RFC5023) merupakan protokol berbasis HTTP buat menciptakan & memperbarui asal daya pada web. Akhir-akhir ini, sebagai poly dipakai buat mengimplementasikan API buat layanan cloud. Contoh yg paling menonjol mungkin merupakan Protokol Data Google[1]. AtomPub dibangun pada atas Format Sindikasi Atom yg adalah representasi XML berdasarkan deretan asal daya yg berubah-ubah (mis. umpan web). Oleh lantaran itu, XQuery sangat cocok buat mengimplementasikan layanan (cloud) berbasis AtomPub.
Kami memakai pelaksanaan AtomPub buat menyajikan pola desain buat XQuery. Aplikasi ini sangat cocok buat poly pola (umum) lantaran sebagian akbar komponennya wajib bisa dipakai pulang sang komponen pelaksanaan lainnya. Selain itu, memanfaatkan perpustakaan yg ada (contohnya buat komunikasi & otentikasi HTTP) memerlukan beberapa keputusan desain yg cermat buat dibuat. Pada dasarnya, pelaksanaan AtomPub terdiri berdasarkan 2 komponen utama: klien & server. Klien merupakan pelaksanaan XQuery yg wajib mengimplementasikan 2 masalah penggunaan dasar berikut:
Kasus Penggunaan 1: Kirim permintaan HTTP buat menciptakan entri Atom.
Kasus Penggunaan 2: Kirim permintaan HTTP buat merogoh entri Atom tertentu. Entri yg didapatkan wajib diubah sebagai HTML.
Server adalah aplikasi yang berjalan di dalam server aplikasi berkemampuan XQuery. Artinya, fungsi dipicu oleh permintaan HTTP. Fungsi-fungsi ini menggunakan modul (HTTP) yang disediakan oleh server aplikasi untuk mengakses konten permintaan HTTP. Server bertindak sebagai mitra untuk permintaan klien. Secara khusus, Anda harus dapat mengatasi dua kasus penggunaan berikut:
Kasus Penggunaan 3: Terima dan simpan item AtomPub. Anda harus dapat menyimpan item di lokasi mana pun, seperti sistem file atau koleksi XQuery.
Use Case 4: Posting tweet untuk setiap item yang dibuat dalam use case 3. Bagian berikut dari artikel ini menunjukkan cara menggunakan pola desain untuk memecahkan masalah desain yang terkait dengan penerapan kasus penggunaan yang dijelaskan. Kita akan mulai dengan Kasus Penggunaan Klien 1 dan 2 di Bagian 3 dan 4, masing-masing. Bagian 5 dan 6 kemudian menjelaskan desain dan implementasi kasus penggunaan 3 dan 4. Tabel berikut menjelaskan pemetaan kasus penggunaan, bagian, fungsi XQuery yang diperlukan, dan nama template yang digunakan untuk mengimplementasikan fitur tersebut.
Rantai Tanggung Jawab
Pada bagian ini, kita akan membahas implementasi use case 1. Dengan kata lain, saya mencoba mengembangkan program XQuery yang menerbitkan catatan Atom ke server yang mendukung AtomPub. Karena tidak semua orang dapat memublikasikan item, server AtomPub memerlukan otentikasi menggunakan mekanisme otentikasi HTTP Basic. Protokol AtomPub menetapkan untuk menerbitkan item dengan mengirimkan permintaan HTTP POST ke server. Payload permintaan ini berisi item yang akan dipublikasikan. Otentikasi HTTP dasar memerlukan nama pengguna dan kata sandi sebagai bagian dari HTTPHeader. Saya telah memilih untuk mengandalkan klien HTTP EXPpath (standar de facto) (lihat HTTPClient) untuk melakukan panggilan HTTP dari program XQuery saya. Klien HTTP ini bekerja dengan melewatkan elemen XDM yang menjelaskan permintaan ke fungsi yang disebut sendrequest. Untuk mengimplementasikan kasus penggunaan pertama, klien AtomPub dapat diimplementasikan dengan ketergantungan kabel antara modul yang bertanggung jawab untuk membuat dan mengirim permintaan HTTP dan modul yang bertanggung jawab untuk otentikasi. Namun, ini jelas membuat klien AtomPub kurang fleksibel dan membuatnya dapat digunakan kembali dalam skenario lain. Misalnya, mengubah mekanisme otentikasi menjadi sesuatu seperti OAuth atau OpenID akan memerlukan perubahan destruktif pada modul AtomPub, jika tidak maka akan membuat basis kode lain yang sangat berlebihan.
Untuk meningkatkan fleksibilitas dan penggunaan kembali aplikasi, kami menetapkan dua persyaratan desain: Klien AtomPub harus dipisahkan dari mekanisme otentikasi
- yang dapat berinteraksi dengannya saat runtime.
- Transport layer, yaitu implementasi spesifik dari klien HTTP.
Untuk memenuhi persyaratan ini, kami mengembangkan klien AtomPub menggunakan pola Rantai Tanggung Jawab. Tujuan dari pola ini adalah untuk:
Kurangi penggabungan antara modul yang berbeda dengan memindahkan dependensi bersarang keluar dari modul dan secara berurutan menggabungkan fungsi dependen ke dalam rantai. Ini melewati elemen ke bawah rantai dan memberikan masing-masing fungsi ini kesempatan untuk memanipulasi atau memanipulasi elemen.
Keterangan
Menerapkan rantai tanggung jawab pada kasus penggunaan kami akan memisahkan kode yang bertanggung jawab untuk mengirim permintaan dan setiap fungsi yang menetapkan permintaan, seperti menyiapkan permintaan ke AtomPub dan menyertakan informasi autentikasi dalam permintaan. Untuk ini kami mendefinisikan anggota berikut:
Request: Mewakili instance XDM dari permintaan HTTP.
Handler: Sebuah fungsi dalam rantai yang menetapkan atau menangani instance permintaan.
Klien: Memulai permintaan, meneruskannya ke semua fungsi dalam rantai, dan mengembalikan hasilnya. Kemampuan penerapan pihak ketiga memudahkan penulisan ulang klien untuk menggunakan strategi autentikasi yang berbeda, misalnya. Secara khusus, ini menghindari hal-hal yang “diketahui” oleh modul perpustakaan yang berbeda, yaitu mereka tidak saling mengimpor.
Penerapan
Bagian ini menjelaskan kemungkinan implementasi use case dengan menerapkan Rantai Pola Tanggung Jawab. Kita akan mulai dengan menjelaskan implementasi klien yang diimplementasikan dalam fungsi yang disebut local:postentry. Kemudian, dua fungsi atompubclient:post dan httpauth:basic dijelaskan. Masing-masing fungsi ini mengambil sebagai parameter pertama elemen kueri yang ditetapkan di badan setiap fungsi. Cuplikan kode di atas mendeklarasikan dan menginisialisasi elemen permintaan HTTP ($request) yang berisi URL server AtomPub. Elemen ini diteruskan melalui rantai fungsi atompubclient:post dan httpauth:basic dan diakhiri dengan panggilan ke fungsi httpclient:sendrequest(). Fungsi terakhir bertanggung jawab untuk mengeksekusi permintaan. Fungsi atompubclient:post() “memijat” elemen permintaan (menggunakan pembaruan XQuery) sesuai dengan spesifikasi AtomPub. Secara khusus, fungsi ini memeriksa apakah metode permintaan HTTP diatur ke POST. Itu juga membangun badan permintaan HTTP untuk mengunduh posting yang akan diterbitkan.
Fungsi httpauth:basic() kemudian menambahkan atribut nama pengguna dan kata sandi ke permintaan dan menetapkan metode otentikasi default. Pedoman Pelaksanaan
Dalam implementasi yang disajikan di bagian terakhir, kami membuat beberapa keputusan untuk membuat artikel lebih mudah dipahami dan meningkatkan keterbacaan kode. Solusi ini tidak esensial atau optimal untuk implementasi rantai tanggung jawab. Jadi pola ini dapat diimplementasikan di XQuery 1.0. Bagian ini menjelaskan beberapa aspek implementasi alternatif.
. Pertimbangan 1. Implementasi klien, pengikatan fungsi terkait menggunakan skrip XQuery. Namun, ada beberapa cara untuk menerapkan rantai. Misalnya, Anda dapat menerapkan rantai menggunakan gaya penerusan lanjutan atau menggunakan serangkaian elemen fungsional yang berjalan secara berurutan.
Catatan 2: Keputusan lain yang saya buat untuk membuat kode lebih mudah dibaca adalah dengan menggunakan fungsi pembaruan XQuery untuk mengimplementasikan fungsi yang relevan (yaitu atompubclient:post dan httpauth:basic). Implementasi alternatif dapat menyalin dan memodifikasi elemen kueri dan mengembalikannya sebagai hasil dari suatu fungsi. Dalam hal ini, klien harus memastikan bahwa elemen yang dikembalikan diteruskan sebagai argumen ke fungsi berikutnya.
