Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. PHP

Dari Prosedural ke Orientasi Objek PHP

by
Difficulty:IntermediateLength:LongLanguages:

Indonesian (Bahasa Indonesia) translation by Dwi Bagus Nurrohman (you can also view the original English article)

Tutorial ini terinspirasi oleh Robert yang diberikan oleh C. C. Martin yang saya tonton setahun yang lalu. Subjek utama dari pembicaraannya adalah tentang kemungkinan memilih Bahasa Pemrograman Terakhir. Dia membahas topik seperti mengapa bahasa tersebut harus ada? Dan seperti apa bentuknya? Namun, jika Anda membaca yang tersirat, ada ide menarik lainnya yang menarik perhatian saya: keterbatasan yang dipaksakan oleh setiap paradigma pemrograman pada kami para pemrogram. Jadi sebelum kita masuk ke bagaimana kita bisa mengubah aplikasi PHP berbasis prosedural menjadi objek yang berorientasi, saya ingin membahas sedikit teori sebelumnya.


Batasan Paradigma

Jadi, setiap paradigma pemrograman membatasi kemampuan kita untuk melakukan apa pun yang ingin kita lakukan. Masing-masing mengambil sesuatu dan memberikan alternatif untuk mencapai hasil yang sama. Pemrograman modular menghilangkan ukuran program yang tidak terbatas. Ini memaksa programmer untuk menggunakan modul berukuran maksimum dan setiap modul diakhiri dengan pernyataan "go-to" ke modul lain. Jadi batasan pertama adalah pada ukuran. Kemudian, pemrograman terstruktur dan pemrograman prosedural menghilangkan pernyataan "go-to" dan membatasi programmer untuk urutan, seleksi dan iterasi. Urutan adalah tugas variabel, pilihan adalah keputusan if-else, dan iterasi adalah loop-sementara. Ini adalah blok bangunan dari sebagian besar bahasa pemrograman dan paradigma hari ini.

Pemrograman berorientasi objek menghilangkan pointer ke fungsi dan memperkenalkan polimorfisme. PHP tidak menggunakan pointer dengan cara yang dilakukan C, tetapi varian dari pointer ke fungsi ini dapat diamati dalam Variable Functions. Ini memungkinkan programmer untuk menggunakan nilai variabel sebagai nama fungsi, sehingga sesuatu seperti ini dapat dicapai:

Ini mungkin tidak terlihat penting pada pandangan pertama. Tetapi pikirkan tentang apa yang bisa kita capai dengan alat yang begitu kuat. Kita dapat mengirim variabel sebagai parameter ke fungsi dan kemudian membiarkan fungsi tersebut memanggil yang lain, direferensikan oleh nilai parameter. Ini luar biasa. Ini memungkinkan kita untuk mengubah fungsi dari suatu fungsi tanpa disadari. Tanpa fungsi pun memperhatikan perbedaan apa pun.

Kami benar-benar dapat melakukan panggilan polimorfik dengan teknik ini juga.

Sekarang, alih-alih memikirkan apa fungsi pointer ke fungsi, pikirkan cara kerjanya. Bukankah mereka hanya menyembunyikan pernyataan "go-to"? Sebenarnya, mereka, atau setidaknya mereka sangat mirip dengan "go-to" tidak langsung. Itu tidak bagus. Apa yang kita miliki di sini sebenarnya adalah cara cerdas untuk "go-to" tanpa menggunakannya secara langsung. Saya harus mengakui bahwa di PHP, seperti yang ditunjukkan contoh di atas, cukup mudah dimengerti, tetapi mungkin membingungkan dengan proyek yang lebih besar dan banyak fungsi yang berbeda yang diteruskan dari satu fungsi ke fungsi lainnya. Di C itu bahkan lebih tidak jelas dan sangat sulit dimengerti.

Namun, hanya mengambil pointer ke fungsi tidak cukup. Pemrograman berorientasi objek harus memberikan pengganti, dan ya, dengan cara yang elegan. Ini menawarkan polimorfisme dengan sintaks yang mudah. Dan dengan polimorfisme, muncul nilai terbesar yang ditawarkan oleh pemrograman berorientasi objek: Aliran kontrol berlawanan dengan ketergantungan kode sumber.

dependency_comparison

Dalam gambar di atas kami mengilustrasikan contoh sederhana tentang bagaimana panggilan polimorfik terjadi dalam dua paradigma yang berbeda. Dalam pemrograman prosedural atau struktural, aliran kontrol mirip dengan ketergantungan kode sumber. Mereka berdua mengarah ke implementasi yang lebih konkret dari perilaku pencetakan.

Dalam pemrograman berorientasi objek, kita dapat membalikkan ketergantungan kode sumber dan membuatnya menunjuk ke arah implementasi yang lebih abstrak, sambil menjaga aliran kontrol yang menunjuk ke implementasi yang lebih konkrit. Ini sangat penting, karena kami ingin kendali kami untuk pergi dan mencapai bagian yang paling konkret dan mudah berubah dari kode kami sehingga kami bisa mendapatkan hasil kami persis seperti yang kami inginkan, tetapi dalam kode sumber kami, kami menginginkan yang sebaliknya. Dalam kode sumber kami, kami menginginkan hal-hal yang konkrit dan mudah berubah untuk tetap keluar dari jalan, agar mudah diubah dan mempengaruhi sesedikit mungkin dari sisa kode kami. Biarkan bagian yang mudah berubah sering berubah tetapi tetap bagian yang lebih abstrak tidak dimodifikasi. Anda dapat membaca lebih lanjut tentang Prinsip Ketergantungan Ketergantungan dalam makalah penelitian asli yang ditulis oleh Robert C. Martin.


Tugas di Tangan

Dalam bab ini kita akan membuat aplikasi sederhana untuk membuat daftar kalender Google dan kejadian di dalamnya. Pertama kita akan mengambil pendekatan prosedural, hanya menggunakan fungsi sederhana dan menghindari jenis kelas atau objek. Aplikasi ini akan memungkinkan Anda untuk mendaftar kalender dan acara Google Anda. Kemudian kami akan mengambil masalah selangkah lebih maju dengan menjaga kode prosedural kami dan mulai mengaturnya dengan perilaku. Akhirnya kita akan mengubahnya menjadi versi berorientasi objek.


PHP Google API Klien

Google menyediakan klien API untuk PHP. Kami akan menggunakannya untuk terhubung ke akun Google kami sehingga kami dapat memanipulasi kalender di sana. Jika Anda ingin menjalankan kode, Anda harus mengatur akun Google Anda untuk menerima pertanyaan kalender.

Meskipun ini adalah persyaratan untuk tutorial, ini bukan subjek utamanya. Jadi alih-alih saya mengulangi langkah-langkah yang harus Anda ambil, saya akan mengarahkan Anda ke dokumentasi yang tepat. Jangan khawatir, pengaturannya sangat mudah dan hanya perlu sekitar lima menit.

Kode klien PHP Google API disertakan dalam setiap proyek dari kode contoh yang dilampirkan pada tutorial ini. Saya sarankan Anda menggunakan yang satu itu. Atau, jika Anda ingin tahu tentang cara menginstalnya sendiri, periksa dokumentasi resmi.

Kemudian ikuti instruksi dan isi informasi dalam file apiAccess.php. File ini akan diperlukan oleh kedua contoh prosedural dan berorientasi objek, sehingga Anda tidak perlu mengulangnya. Saya meninggalkan kunci saya di sana sehingga Anda dapat lebih mudah mengidentifikasi dan mengisi milik Anda.

Jika Anda menggunakan NetBeans, saya meninggalkan file proyek di folder yang berisi contoh yang berbeda. Dengan cara ini Anda dapat membuka proyek dan menjalankannya langsung di server PHP lokal (PHP 5.4 diperlukan) hanya dengan memilih Run / Run Project.

Pustaka klien untuk terhubung ke Google API berorientasi objek. Demi contoh fungsional kami, saya menulis serangkaian fungsi kecil yang membungkusnya, fungsionalitas yang kami butuhkan. Dengan cara ini, kita dapat menggunakan lapisan prosedural yang ditulis di atas perpustakaan klien berorientasi objek sehingga kode kita tidak perlu menggunakan objek.

Jika Anda ingin cepat menguji bahwa kode dan koneksi Anda ke Google API berfungsi, cukup gunakan kode di bawah ini sebagai file index.php Anda. Ini harus mencantumkan semua kalender yang Anda miliki di akun Anda. Setidaknya harus ada satu kalender dengan bidang ringkasan yang menjadi nama Anda. Jika Anda memiliki kalender dengan ulang tahun kontak Anda, yang mungkin tidak berfungsi dengan Google API ini, tetapi jangan panik, cukup pilih yang lain.

File index.php ini akan menjadi titik masuk ke aplikasi kita. Kami tidak akan menggunakan kerangka web atau sesuatu yang mewah. Kami hanya akan menampilkan beberapa kode HTML.


Pendekatan Prosedur Langsung

Sekarang kita tahu apa yang sedang kita bangun dan apa yang akan kita gunakan, lanjutkan dan unduh kode sumber yang terlampir. Saya akan memberikan cuplikan dari itu, tetapi untuk melihat semuanya, Anda akan ingin memiliki akses ke sumber aslinya.

Untuk pendekatan ini, kami hanya ingin bekerja. Kode kami akan diatur dengan cara yang sangat sederhana, dengan hanya beberapa file, seperti ini:

  • index.php - satu-satunya file yang kita akses langsung dari browser dan memberikannya ke GET parameter.
  • functions_google_api.php - pembungkus atas Google API yang kami bicarakan di atas.
  • functions.php - di mana semuanya terjadi.

functions.php akan menampung semua yang dilakukan aplikasi kami. Baik logika routing, presentasi, dan nilai dan perilaku apa pun dapat dikubur di sana. Aplikasi ini cukup sederhana, logika utamanya adalah sebagai berikut.

procedural_schema

Kami memiliki satu fungsi yang disebut doUserAction(), yang memutuskan dengan pernyataan if-else panjang, yang metode lain untuk memanggil berdasarkan parameter dalam variabel GET. Metode kemudian terhubung ke kalender Google menggunakan API dan mencetak ke layar apa pun yang ingin kami minta.

Contoh ini mungkin merupakan fungsi yang paling rumit dalam kode kami. Ini memanggil fungsi pembantu bernama putTitle(), yang hanya mencetak beberapa HTML yang diformat untuk judul. Judul akan berisi nama untuk kalender kami yang dapat diperoleh dengan memanggil getCalendar() dari functions_google_api.php. Kalender yang dikembalikan akan berupa larik, berisi bidang summary. Itulah yang kita kejar.

Variabel $client dilewatkan di semua tempat di semua fungsi kami. Diperlukan untuk terhubung ke Google API. Kami akan membahas ini nanti.

Selanjutnya, kita menggilir semua peristiwa dalam kalender saat ini. Daftar larik ini diperoleh dengan menjalankan panggilan API yang dienkapsulasi di retrieveEvents(). Untuk setiap acara, kami mencetak tanggal dibuat dan kemudian judulnya.

events_in_a_calendar

Sisa dari kode ini mirip dengan apa yang telah kita bahas dan bahkan lebih mudah dipahami. Jangan ragu untuk bermain-main dengan itu sebelum melanjutkan ke bagian selanjutnya.


Mengatur Kode Prosedural

Kode kami saat ini baik-baik saja, tetapi saya pikir kami dapat melakukannya dengan lebih baik dan mengaturnya dengan cara yang lebih tepat. Anda dapat menemukan proyek dengan kode terorganisir lengkap dengan nama "GoogleCalProceduralOrganized" di kode sumber terlampir.

Menggunakan Variabel Global Client

Hal pertama yang mengganggu saya tentang kode tidak terorganisir kami, adalah bahwa kami melewatkan variabel $client ini sebagai argumen di semua tempat, beberapa level jauh di dalam fungsi yang disarangkan. Pemrograman prosedural memiliki cara cerdas untuk memecahkan ini, sebuah variabel global. Karena $client didefinisikan dalam index.php dan dalam lingkup global, semua yang harus kita ubah adalah bagaimana fungsi-fungsi kita menggunakannya. Jadi alih-alih mengharapkan parameter $client, kita dapat menggunakan:

Bandingkan kode saat ini dengan kode yang baru diorganisasikan untuk melihat perbedaannya. Alih-alih mengirimkan $ client sebagai parameter, kami menggunakan global $client di semua fungsi kami dan memberikannya sebagai parameter hanya untuk fungsi Google API. Secara teknis, bahkan fungsi Google API dapat menggunakan variabel $client dari lingkup global, tapi saya pikir lebih baik untuk menjaga API sebagai independen mungkin.

Memisahkan Presentasi Dari Logika

Beberapa fungsi jelas, hanya untuk mencetak hal-hal di layar, yang lain untuk memutuskan apa yang harus dilakukan, dan beberapa lagi sedikit dari keduanya. Ketika ini terjadi, kadang-kadang yang terbaik untuk memindahkan fungsi-fungsi tujuan-spesifik ke dalam file mereka sendiri. Kita akan mulai dengan fungsi yang digunakan murni untuk mencetak sesuatu ke layar, ini akan dipindahkan ke file functions_display.php. Lihat di bawah ini.

Sisa dari proses memisahkan presentasi kami dari logika mengharuskan kami untuk mengekstrak bagian presentasi dari metode kami. Di sini adalah bagaimana kami melakukannya dengan salah satu metode.

Jelas kita dapat melihat bahwa apa pun yang ada di dalam pernyataan if hanyalah kode presentasi dan sisanya adalah logika bisnis. Alih-alih satu fungsi besar yang menangani semuanya, kami akan memecahnya menjadi beberapa fungsi:

Setelah pemisahan, logika bisnis sekarang sangat sederhana. Kami bahkan mengekstraksi metode kecil untuk menentukan apakah acara tersebut adalah yang sekarang. Semua kode presentasi sekarang menjadi tanggung jawab fungsi bernama putEvent($event) yang berada di file functions_display.php:

Meskipun metode ini hanya menampilkan informasi, kita harus ingat bahwa itu tergantung pada pengetahuan yang mendalam tentang struktur $event. Tapi, ini tidak masalah untuk saat ini. Adapun sisa metode, mereka dipisahkan dengan cara yang sama.

Menghilangkan Pernyataan Panjang if-else

Hal terakhir yang mengganggu saya tentang kode kami saat ini adalah pernyataan panjang if-else dalam fungsi doUserAction() kami, yang digunakan untuk memutuskan apa yang harus dilakukan untuk setiap tindakan. Sekarang, PHP cukup fleksibel ketika datang ke meta-programming (memanggil fungsi dengan referensi). Trik ini memungkinkan kita untuk mengkorelasikan nama fungsi dengan nilai variabel $ _GET. Jadi kita dapat memperkenalkan parameter action tunggal dalam variabel $ _GET dan menggunakan nilai dari itu sebagai nama fungsi.

Berdasarkan pendekatan ini, menu kami akan dibuat seperti ini:

Seperti yang Anda mungkin lihat, reorganisasi ini sudah mendorong kami menuju desain berorientasi objek. Tidak jelas benda-benda apa yang kita miliki dan dengan perilaku persis apa, tetapi kita memiliki beberapa petunjuk di sini-dan-di sana.

Kami memiliki presentasi yang bergantung pada tipe data dari logika bisnis. Ini menyerupai inversi ketergantungan yang kita bicarakan di bab pendahuluan. Aliran kontrol masih dari logika bisnis menuju presentasi, tetapi ketergantungan kode sumber mulai berubah menjadi ketergantungan terbalik. Saya akan mengatakan, pada titik ini lebih seperti ketergantungan dua arah.

Petunjuk lain dari desain berorientasi objek adalah sedikit meta-programming yang baru saja kita lakukan. Kami menyebutnya metode, yang tidak kami ketahui. Itu bisa apa saja dan itu seperti kita berurusan dengan tingkat polimorfisme yang rendah.

Analisis Ketergantungan

Untuk kode kami saat ini, kami dapat menggambar skema, seperti skema di bawah ini, untuk mengilustrasikan beberapa langkah pertama melalui aplikasi kami. Menggambar semua garis akan terlalu rumit.

organized_procedural_schema

Kami ditandai dengan garis biru, panggilan prosedur. Seperti yang Anda lihat mereka mengalir ke arah yang sama seperti sebelumnya. Selain itu kami memiliki garis hijau yang menandai panggilan tidak langsung. Ini semua melewati doUserAction(). Dua jenis garis ini mewakili aliran kontrol, dan Anda dapat mengamati bahwa itu pada dasarnya tidak berubah.

Namun garis merah memperkenalkan konsep yang berbeda. Mereka mewakili ketergantungan kode sumber dasar. Maksud saya belum sempurna, karena tidak begitu jelas. Metode putMenu() menyertakan nama fungsi yang harus dipanggil untuk tautan tertentu. Ini adalah ketergantungan dan aturan yang sama berlaku untuk semua metode lain membuat tautan. Mereka bergantung pada perilaku fungsi lainnya.

Ketergantungan jenis kedua juga dapat dilihat di sini. Ketergantungan pada data. Saya sebelumnya menyebutkan $calendar dan $event. Fungsi pencetakan harus memiliki pengetahuan yang mendalam tentang struktur internal array ini untuk melakukan pekerjaannya.

Jadi setelah semua itu, saya pikir kami punya banyak alasan untuk beralih ke langkah terakhir kami.


Solusi Berorientasi Objek

Terlepas dari paradigma yang digunakan, tidak ada solusi sempurna untuk masalah. Jadi di sini adalah bagaimana saya mengusulkan untuk mengatur kode kami dalam cara yang berorientasi objek.

Naluri Pertama

Kami sudah mulai memisahkan kekhawatiran dalam logika bisnis dan presentasi. Kami bahkan mempresentasikan metode doUserAction() kami sebagai entitas terpisah. Jadi insting pertama saya adalah membuat tiga kelas Presenter, Logic, dan Router. Ini kemungkinan besar akan berubah nanti, tetapi kita perlu tempat untuk memulai, bukan?

Router hanya akan berisi satu metode dan akan tetap cukup mirip dengan implementasi sebelumnya.

Jadi sekarang kita harus secara eksplisit memanggil metode putMenu() menggunakan objek Presenter baru dan sisa tindakan akan dipanggil menggunakan objek Logic. Namun, ini segera menyebabkan masalah. Kami memiliki tindakan yang tidak ada di kelas Logika. putHome() ada di kelas Presenter. Kita perlu memperkenalkan tindakan dalam Logic yang akan didelegasikan ke metode PutHome() Presenter. Ingat, untuk saat ini kami hanya ingin membungkus kode yang ada ke dalam tiga kelas yang kami identifikasi sebagai kandidat yang mungkin untuk desain OO. Kami hanya ingin melakukan apa yang benar-benar diperlukan untuk membuat karya desain. Setelah kami memiliki kode kerja, kami akan mengubahnya lebih lanjut.

Segera setelah kami menempatkan metode putHome() ke dalam kelas Logika, kami mengalami dilema. Bagaimana cara memanggil metode dari Presenter? Yah, kita bisa membuat dan meneruskan objek Presenter ke Logic sehingga selalu memiliki referensi ke presentasi. Mari kita lakukan itu dari Router kita.

Sekarang kita dapat menambahkan konstruktor dalam Logika dan menambahkan delegasi ke arah putHome() di Presenter.

Dengan sedikit penyesuaian pada index.php dan memiliki Presenter yang membungkus metode tampilan lama, Logic membungkus fungsi logika bisnis lama, dan Router membungkus pemilih tindakan yang lama, kita benar-benar dapat menjalankan kode kita dan memiliki elemen menu "Rumah" berfungsi.

Dan ini dia beraksi.

oo_home_working

Selanjutnya, di kelas Logika kami, kami perlu benar-benar mengubah panggilan untuk menampilkan logika, untuk bekerja dengan $this->presenter. Kemudian kita memiliki dua metode - isCurrentEvent() dan retrieveEvents() - yang hanya digunakan di dalam kelas Logika. Kami akan membuat mereka pribadi dan mengubah panggilan yang sesuai.

Kami kemudian akan mengambil pendekatan yang sama dengan kelas Presenter. Kami akan mengubah semua panggilan ke metode untuk menunjuk ke $this-> something dan membuat putTitle(), putLink (), dan putBlock () pribadi, karena mereka hanya digunakan dari Presenter. Periksa kode di direktori GoogleCalObjectOrientedInitial di kode sumber terlampir jika Anda mengalami kesulitan dalam melakukan semua perubahan ini sendiri.

Pada titik ini kami memiliki aplikasi yang berfungsi. Hal ini sebagian besar kode prosedural dibungkus dalam sintaks OO, yang masih menggunakan variabel global $client dan memiliki banyak bau anti-object-oriented lainnya, tetapi itu berhasil.

Jika kita menggambar diagram kelas dengan dependensi untuk kode ini, maka akan terlihat seperti ini:>

oo_initial_class_diagram

Baik kontrol aliran dan ketergantungan kode sumber melalui router, kemudian logika, dan akhirnya melalui presentasi. Perubahan terakhir yang kami lakukan benar-benar memudar sedikit dari inversi dependensi yang kami amati pada langkah sebelumnya. Tapi jangan biarkan dirimu dibodohi. Prinsipnya ada di sana, kita harus membuatnya jelas.

Mengembalikan Ketergantungan Kode Sumber

Sulit untuk mengatakan bahwa satu prinsip SOLID lebih penting daripada yang lain, tetapi saya pikir Prinsip Ketergantungan Pembalikan memiliki dampak langsung terbesar pada desain Anda. Prinsip ini menyatakan:

A: Modul tingkat tinggi tidak boleh bergantung pada modul tingkat rendah. Keduanya harus bergantung pada abstraksi dan B: Abstraksi tidak boleh bergantung pada detail. Detail harus bergantung pada abstraksi.

Sederhananya, ini berarti bahwa implementasi konkrit harus bergantung pada kelas abstrak. Ketika kelas Anda menjadi abstrak, semakin sedikit mereka cenderung berubah. Jadi Anda dapat melihat masalah sebagai: kelas yang sering berubah harus bergantung pada kelas lain yang lebih stabil. Jadi bagian yang paling mudah berubah dari aplikasi apa pun mungkin adalah antarmuka penggunanya, yang akan menjadi kelas Presenter dalam aplikasi kita. Mari kita buat pembalikan ketergantungan ini dengan jelas.

Pertama kita akan membuat Router kita hanya menggunakan Presenter dan merusak ketergantungannya pada Logic.

Kemudian kita akan mengubah Presenter untuk menggunakan contoh Logika dan menanyakannya untuk informasi yang diperlukan untuk ditampilkan. Dalam kasus kami, saya menganggap dapat diterima bagi Presenter untuk benar-benar membuat instance Logika, tetapi dalam sistem produksi apa pun, Anda kemungkinan akan memiliki Pabrik yang membuat objek terkait logika bisnis dan menyuntikkannya ke dalam lapisan presentasi.

Sekarang, fungsi putHome(), hadir di kedua kelas Logika dan Presenter, akan hilang dari Logika. Ini adalah pertanda baik, karena kami menghapus duplikasi. Konstruktor dan referensi ke Presenter juga menghilang dari Logic. Di sisi lain, konstruktor yang menciptakan objek Logic harus ditulis pada Presenter.

Setelah perubahan itu, mengklik Show Calendars akan menghasilkan kesalahan yang bagus. Karena semua tindakan kami dari dalam tautan mengarah ke nama fungsi di kelas Logika, kami harus melakukan beberapa perubahan lebih konsisten untuk membalikkan ketergantungan di antara keduanya. Mari kita ambil satu metode dalam satu waktu. Pesan kesalahan pertama mengatakan:

Jadi, Router kami ingin memanggil metode yang tidak ada di Presenter, printCalendars(). Mari kita buat metode itu di Presenter dan periksa apa yang dilakukannya di Logic. Ini mencetak judul dan kemudian bersepeda melalui beberapa kalender dan disebut putCalendar(). Di Presenter, metode printCalendars() akan terlihat seperti ini:

Di sisi lain, di Logic, metodenya menjadi sangat anemia. Hanya panggilan ke depan ke pustaka Google API.

Ini mungkin membuat Anda bertanya pada diri sendiri dua pertanyaan, "Apakah kita benar-benar membutuhkan kelas Logika?" dan "Apakah aplikasi kami bahkan memiliki logika apa pun?". Yah, kita belum tahu. Untuk sementara waktu kami akan melanjutkan proses di atas, sampai semua kode berfungsi, dan Logika tidak bergantung pada Presenter lagi.

Jadi, kita akan menggunakan metode printCalendarContents() di Presenter, seperti yang di bawah ini:

Yang pada gilirannya, akan memungkinkan kita untuk menyederhanakan getEventsForCalendar() dalam Logic, menjadi sesuatu seperti ini.

Sekarang ini berhasil, tetapi saya memiliki kekhawatiran di sini. Variabel $ _GET digunakan baik dalam kelas Logika dan Presenter. Bukankah seharusnya hanya kelas Presenter yang menggunakan $ _GET? Maksudku, Presenter benar-benar perlu tahu tentang $ _GET karena harus membuat tautan yang mengisi variabel $ _GET ini. Jadi itu berarti bahwa $ _GET secara ketat terkait dengan HTTP. Sekarang, kami ingin kode kami bekerja dengan UI grafis CLI atau desktop. Jadi kami ingin menyimpan pengetahuan ini hanya di Presenter. Ini membuat dua metode dari atas, berubah menjadi dua di bawah ini.

Sekarang fungsi terakhir yang harus kita hadapi adalah mencetak acara tertentu. Demi contoh ini, anggap tidak ada cara kita dapat mengambil suatu peristiwa secara langsung dan kita harus menemukannya sendiri. Sekarang kelas Logika kami sangat berguna. Ini adalah tempat yang sempurna untuk memanipulasi daftar acara dan mencari ID tertentu:

Dan kemudian panggilan yang sesuai di Presenter akan mengurus pencetakannya:

Itu dia. Di sini kita. Ketergantungan terbalik!

oo_dip_class_diagram

Kontrol masih mengalir dari Logika menuju Presenter. Konten yang disajikan benar-benar ditentukan oleh Logika. Jika, misalnya besok, kami ingin terhubung ke layanan kalender lain, kami dapat membuat Logika lain, menyuntikkannya ke Presenter, dan Presenter bahkan tidak akan melihat perbedaan apa pun. Juga, ketergantungan kode sumber berhasil dibalikkan. Presenter adalah satu-satunya yang menciptakan dan secara langsung bergantung pada Logika. Ketergantungan ini sangat penting dalam memungkinkan Presenter untuk mengubah cara menampilkan data, tanpa mempengaruhi apa pun di Logika. Selain itu, ini memungkinkan kita untuk mengubah HTML Presenter kami dengan CLI Presenter atau metode lain untuk menampilkan informasi kepada pengguna.

Menyingkirkan Variabel Global

Mungkin cacat desain serius yang tersisa terakhir adalah penggunaan variabel global untuk $client. Semua kode di aplikasi kami memiliki akses ke sana. Ajaib, satu-satunya kelas yang benar-benar membutuhkan $client adalah kelas Logika kami. Langkah yang jelas adalah membuat variabel kelas privat. Tetapi hal ini mengharuskan kami untuk mempropagandakan $client melalui Router, ke dalam Presenter, sehingga dapat membuat objek Logic dengan variabel $client. Ini memecahkan sedikit masalah kita. Kita perlu membangun kelas-kelas kita di tempat yang terisolasi dan menyuntikkan dependensi satu sama lain dengan tepat.

Untuk struktur kelas yang lebih besar, kami akan menggunakan Pabrik, tetapi untuk contoh kecil kami, file index.php akan menjadi tempat yang bagus untuk menyimpan logika pembuatan. Dan menjadi titik masuk ke aplikasi kami, alias file "utama" dalam skema arsitektur tingkat tinggi, itu masih di luar batas logika bisnis kami.

HighLevelDesign

Jadi kami mengubah index.php menjadi kode di bawah ini, menjaga semua termasuk dan session_start () perintah:


Pikiran Akhir

Dan kita selesai. Pasti ada beberapa hal lain yang bisa kami lakukan untuk membuat desain kami menjadi lebih baik. Jika tidak ada yang lain, kita bisa menulis beberapa tes untuk metode kami di kelas Logika. Mungkin kelas Logic kami juga dapat diganti menjadi sesuatu yang lebih representatif, seperti GoogleCalendarGateway. Atau kita bisa membuat kelas Event dan Kalender untuk lebih mengontrol data dan perilaku pada konsep-konsep ini dan memutus ketergantungan Presenter pada array untuk tipe data ini. Peningkatan dan perluasan lain adalah dengan benar-benar membuat kelas aksi polimorfik daripada hanya memanggil fungsi dengan referensi dari $_GET. Ada hal-hal kecil yang tak ada habisnya yang bisa kita lakukan untuk lebih meningkatkan bahkan desain sederhana ini. Saya akan memberi Anda kesempatan besar untuk bereksperimen, mulai dari versi terakhir kode ini yang dapat Anda temukan di arsip terlampir di bawah direktori GoogleCalObjectOrientedFinal.

Jika Anda suka berpetualang, Anda dapat memperluas aplikasi kecil ini untuk terhubung ke layanan kalender lain dan menyajikan informasi dengan cara yang berbeda dan pada platform yang berbeda. Untuk Anda semua yang menggunakan NetBeans, setiap folder kode sumber berisi proyek NetBeans, jadi Anda harus dapat membukanya secara langsung. Di versi final, PHPUnit juga disiapkan untuk Anda, tetapi di sisa proyek, saya menghapusnya karena kami tidak melakukan pengujian.

Terimakasih Telah Membaca

Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.