1. Implementasi objek bisnis. Kelas yang merangkum aturan bisnis adalah dasar dari pemrograman berorientasi objek yang sebenarnya. Pada artikel ini, kita akan membahas semua aspek pemrograman dan mempertanyakan beberapa cara yang biasa kita gunakan dalam menulis program Delphi. Konsep dasar di balik metode desain ini adalah enkapsulasi: merancang sekumpulan kelas dengan antarmuka (metode) yang didefinisikan dengan jelas yang memiliki metode untuk mengoperasikan propertinya. Konsep ini akan digunakan di seluruh program dan memiliki dampak yang kuat terhadap cara data disimpan dan disajikan. Saya ingin memperkenalkan kepada pembaca artikel Francis Glassborow tentang C++. Meskipun bahasanya berbeda, konsep desain kelas yang bagus tidak bergantung pada bahasa. Kebanyakan program yang ditulis dalam Delphi saat ini tidak berorientasi objek. Hanya karena ada model objek dalam bahasa tersebut dan menggunakan kelas asli atau baru, ini tidak berarti bahwa program tersebut benar-benar berorientasi objek. Penggunaan kembali kode berakhir ketika kontrol pihak ketiga diseret ke jendela, namun saling ketergantungan antara jendela dan unit berkembang biak dengan cepat. (!!!) Jika Anda ingin mengubah basis program di masa depan (seperti beralih ke database lain atau beralih dari struktur dua tingkat ke struktur tiga tingkat), hal ini akan sangat terhambat atau mahal. Jika program ini benar-benar ditulis dengan cara berorientasi objek, maka akan lebih mudah daripada membatasi. Tentu saja, menulis program seperti itu memerlukan perbaikan konsep, dan produktivitas pada awalnya kurang. Kebanyakan tim pengembangan tidak mau melakukan atau mempertimbangkan hal ini. Saya berharap melalui artikel ini saya akan menunjukkan kepada Anda bagaimana menulis program yang lebih baik. Hasilnya adalah sistem yang lebih dapat diandalkan, mudah dipelihara, gayanya konsisten, fleksibel, dapat digunakan kembali, dan berjalan lebih baik dibandingkan program yang ditulis dengan cara tradisional. Khusus untuk program besar, program yang kodenya jelas dan benar-benar berorientasi objek akan memerlukan sumber daya pemeliharaan yang lebih sedikit dibandingkan program yang sama yang ditulis dengan cara tradisional. Keandalan yang lebih besar dari program berorientasi objek berasal dari fakta bahwa data dan operasi dikemas dalam kelas yang terdefinisi dengan baik. Kompiler menerapkan kelas, metode, dan properti yang benar dalam kode melalui pemeriksaan tipe yang kuat, dan tidak boleh ada kemungkinan kesalahpahaman maksud kode jika perubahan di masa mendatang memengaruhi keseluruhan program. Ketika kelas digunakan dengan benar, hubungan di antara mereka menjadi jelas, dan sebagian besar kode benar-benar terfokus pada inti program, daripada memikirkan detail seperti bagaimana data disimpan. Kesederhanaan dan konsistensi di seluruh kode akan meningkatkan pemeliharaan program secara signifikan. Seperti yang akan kita lihat, penggunaan pewarisan kelas secara ekstensif meningkatkan produktivitas dan keandalan, serta meningkatkan konsistensi. Konsistensi ini tercermin dalam kode yang ditampilkan, termasuk perilaku kelas, cara data disimpan, dan cara antarmuka pengguna menyajikan data. Karena sebagian besar fungsi disediakan di kelas dasar, Anda dapat mengubah program secara mendasar dengan mengubah perilakunya secara cepat. (Misalnya, antarmuka interaksi pengguna diubah dari bentuk berbasis jendela menjadi berbasis HTML) Kelas dasar ini dapat dirancang agar tidak bergantung pada program, sehingga program kedua yang serupa akan segera mendapatkan peningkatan produktivitas. Serangkaian kelas dasar yang baik dapat memberikan peningkatan yang signifikan hingga 50% untuk program sederhana dalam hal waktu, biaya, dan keandalan. Hal pertama yang perlu ditekankan adalah bahwa beralih ke pengembangan berorientasi objek yang sebenarnya bukanlah hal yang sepele. Untuk pertama kalinya, Anda harus memastikan bahwa Anda telah merasakan bantuan, atau programnya kecil dan tidak ada tenggat waktu pengiriman yang mendesak; Perlu dicatat bahwa berorientasi objek (OO) Solusinya adalah tidak mendikte kelas mana yang harus digunakan dan kelas mana yang tidak boleh digunakan dalam program. Jika sebuah perusahaan mengembangkan kontrol visualnya sendiri, atau menggunakan kontrol visual pihak ketiga, kelas inti. Langkah pertama dalam merancang program berorientasi objek adalah mempertimbangkan kelas mana yang diperlukan. Ini adalah langkah yang sangat mendasar, tergantung pada jaminan teknis dari berbagai perkembangan lainnya, karena kesalahan pada tahap awal akan memakan biaya besar untuk memperbaikinya. Saat merancang kelas, kami umumnya berusaha mencapai kopling rendah dan kohesi tinggi - kelas bersifat independen, namun dapat digabungkan dengan cara yang ampuh. Salah satu cara untuk mencapai tujuan ini adalah dengan membagi kelas ke dalam kategori berbeda sesuai dengan peran berbeda yang mereka mainkan dalam program mereka. Pemilihan peran-peran ini yang benar akan menghasilkan serangkaian kelas yang kohesif. Ada prinsip dasar yang konsisten dalam desain peran kelas: membagi tanggung jawab kelas menjadi presentasi, penerapan, dan penyimpanan data yang persisten (biasanya dalam database). Meskipun ini sama dengan partisi program database tiga tingkat, penting untuk dicatat bahwa konsep partisi ini dapat diimplementasikan dalam berbagai lingkungan: dari program chip tunggal hingga program multi-tier terdistribusi. Kelompok kelas yang membentuk logika aplikasi bertanggung jawab atas pekerjaan yang paling sulit, seperti menanggapi permintaan tindakan pengguna dan memproses data. Beberapa kelas pada lapisan ini mewakili entitas dunia nyata dan dimodelkan oleh sistem. Kelas-kelas ini sering disebut "kelas bisnis" atau "kelas domain masalah". Mereka merupakan bagian penting dari setiap program berorientasi objek, dan karena kelas-kelas lain akan mendukung kelas-kelas ini dalam beberapa cara, mereka menjadi fokus semua pengembang. Mengidentifikasi objek bisnis mana yang ada dalam program tertentu umumnya merupakan masalah pengalaman dan naluri, meskipun terdapat keseluruhan disiplin (atau seni?) dalam proses ini. Keunggulan orientasi objek dibandingkan teknik tradisional seperti SSADM(1) juga ada sepanjang analisis, desain dan Proses pemeliharaan entitas: Setiap objek bisnis dapat direpresentasikan melalui analisis berorientasi objek (OOA), desain berorientasi objek (OOD), dan pemrograman berorientasi objek (OOP). Kami akan mengeksplorasi beberapa teknik untuk mengidentifikasi target bisnis yang sesuai nanti. Pertama kita asumsikan bahwa proses berikut telah selesai. Interkomunikasi kelas antara lapisan yang berbeda (presentasi, penerapan, dan persistensi) didefinisikan dengan jelas dan saling berhubungan. Hubungan antara kelas-kelas ini ditunjukkan pada Gambar 1. Tanda panah pada gambar menunjukkan bahwa kelas-kelas di lapisan yang sama dapat memanggil metode di kelas lain. Gambar ini juga menunjukkan bahwa kelas-kelas lapisan presentasi (antarmuka pengguna) dapat mengoperasikan lapisan aplikasi atau kelas-kelas lain di antarmuka pengguna. Lapisan aplikasi (objek bisnis) dapat mengoperasikan kelas-kelas lapisan aplikasi dan memanggil metode persistensi lapisan. Lapisan persistensi hanya merespons permintaan lapisan aplikasi. Objek Bisnis Untuk mendemonstrasikan bagaimana objek bisnis diimplementasikan, selanjutnya kita akan melihat program yang disederhanakan dengan entitas inventaris, pelanggan, dan pesanan (perusahaan menyediakan sejumlah barang, dan pelanggan membeli barang tersebut). Analisis awal kami menentukan bahwa tiga objek bisnis diperlukan untuk mewakili entitas ini. Akan ada tiga kelas dalam program Delphi kami: TStockItem, TCustomer dan Torder. Antarmuka publik dari kelas-kelas ini ditunjukkan pada Listing 1. Harus ditunjukkan di sini bahwa karakteristik kelas-kelas ini diekspos ke luar melalui properti (PRerty): ini adalah desain kelas yang sederhana dan bermanfaat serta mengontrol akses eksternal melalui properti. Selain itu, properti ini harus berada di area publikasi kelas (untuk alasan yang akan disebutkan nanti) dan diberi nilai default yang sesuai. Meskipun kualifikasi properti ini hanya digunakan saat streaming kelas, kualifikasi ini memberikan setiap properti nilai awal yang sesuai dan membuat kode lebih menggambarkan dirinya sendiri. Kerangka Kelas Satu Pada tahap awal pengembangan program, kami telah mengidentifikasi dan mengimplementasikan tiga objek bisnis. Ketiga objek ini memainkan peran yang sama: mewakili entitas dunia nyata dalam beberapa cara. Oleh karena itu kami ingin mereka memiliki properti yang serupa dan level yang sesuai dengan entitas dunia nyata. Kami akan memberikan setiap objek kelas dasar umum yang disebut TPDObject (Objek Domain Masalah). Seiring waktu kami akan menambahkan metode dan properti publik ke kelas ini, dan TPDObject akan terus diperluas. Perlu dicatat bahwa TPDObject tidak boleh (tidak pernah) memiliki elemen apa pun yang terkait dengan aplikasi tertentu. Sebagai kelas yang tidak bergantung pada program, kelas ini ditempatkan dalam unit independen dan membentuk dasar kerangka kerja: sekumpulan kelas yang dapat digunakan kembali dalam banyak program. Di masa depan, kerangka kerja kami akan diperluas secara signifikan untuk membentuk kelas dasar yang menyediakan fungsi penting yang tidak bergantung pada program dan dapat dengan cepat digunakan dalam sistem tertentu. TStockItem, TCustomer, dan Torder kami adalah objek yang disesuaikan untuk sistem tertentu dari TPDObject. TMyAppPDObject adalah kelas yang diwarisi dari TPDObject. Meskipun bagian implementasinya kosong, ini adalah demonstrasi yang bagus jika kita menambahkan elemen tertentu ke program tertentu dan mempengaruhi semua kelas domain masalah dalam program tersebut, seperti ini Hirarki kelas seharusnya lebih tepat. Kode awal untuk kerangka kerja tercantum dalam daftar. Kelas TPDObject juga hanya menyediakan ID atribut read-only, tipenya adalah TobjectID. Atribut ini memberikan pengenal pada setiap objek: kita akan menganggap dua instance dengan tipe dan ID yang sama sebagai objek yang sama. Di sini ID sengaja dideklarasikan sebagai tipenya sendiri untuk menghindari penetapan langsung ke nilai tipe standar lain. Jenis TobjectID tidak dipilih secara spesifik: di sini saya memilih bilangan bulat, yang mungkin juga merupakan kelas khusus dalam kasus tertentu. Meskipun menggunakan kelas sebagai ID tampaknya merupakan pendekatan berorientasi objek yang lebih murni, berdasarkan fakta bahwa kelas dalam domain masalah kita akan dibuat dan dirilis ribuan kali selama menjalankan program, untuk menghindari beban tambahan saat membuat dan melepaskan objek, saya tidak melakukan ini (Sebagai seorang puritan saya menyertakan TobjectID di TPDObject sebagai objek komposit). Dalam kode tersebut terdapat sepasang fungsi yang mengubah string menjadi tipe identifikasi objek kita, dan sebuah konstanta yang berfungsi sebagai nilai awal ketika tidak ada penugasan yang dilakukan. Ada banyak kelas di mana identifikasi objek disebutkan: ada yang mengatakan bahwa semua objek bisnis harus diberi identifikasi (bahkan GUID) yang tidak diulangi dalam program saat dibuat. Faktanya, kemampuan membedakan berbagai objek dalam konteks tertentu adalah hal yang sangat penting, dan menjaga hal ini tetap sederhana akan memberikan manfaat kinerja dan ruang penyimpanan yang jelas. Pertanyaan tentang spesifikasi: Untuk memperkuat beberapa konsep dan praktik desain saat merancang kerangka kelas, saya akan mengajukan beberapa pertanyaan dan meminta pembaca untuk memikirkan prinsip dasar di baliknya. Saya menyebutkan bahwa desain berorientasi objek yang sebenarnya tidak melarang penggunaan kelas tertentu, namun ada satu pengecualian penting. Apa pengecualian ini (jawabannya ada di Gambar 1) ((( Listing 1 - Unit Domain Masalah khusus aplikasi (ringkasan) )))unit ProblemDomain;interfaceuses Framework;type TMyAppPDObject = class (TPDObject) end; TMyAppPDObject ) properti yang diterbitkan Nama: String; properti QuantityInStock: Kardinal default 0; properti TradePrice: Mata uang; properti RetailPrice: Mata uang; TPelanggan = kelas (TMyAppPDObject) … ; TOrder = kelas (TMyAppPDObject) … ;implementationend.((( Daftar Akhir 1 )))((( Daftar 2 - Unit Kerangka yang tidak bergantung pada aplikasi )))kerangka unit;interfaceconst NotAssigned = 0; ketik TObjectID = ketik Integer; TPDObject = kelas privat FID: TObjectID; ID properti publik: TObjectID baca FID default NotAssigned; end;function StrToID (Nilai: String): TObjectID;function IDToStr (Nilai: TObjectID): String;implementasi…end.((( End Listing 2 )))(1) SSADM (Analisis Sistem Terstruktur & Desain Sistem) didirikan pada 1981 Situs web Badan Komputer dan Telekomunikasi Pusat Pemerintah Inggris: http://www.ccta.gov.uk ) mengembangkan metode standar analisis dan desain perangkat lunak. Philip Brown adalah konsultan desain sistem dan pengembang aktif, presenter, dan pelatih. Dia akan mempromosikan manfaat teknik OO yang kuat untuk memberikan aplikasi yang lebih baik jika ada kesempatan.