Desain Properti
Catatan
Konten ini dicetak ulang oleh izin Pearson Education, Inc. dari Panduan Desain Kerangka Kerja: Konvensi, Idiom, dan Pola untuk Pustaka .NET yang Dapat Digunakan Kembali, Edisi ke-2. Edisi itu diterbitkan pada tahun 2008, dan buku tersebut telah sepenuhnya direvisi pada edisi ketiga. Beberapa informasi di halaman ini mungkin sudah kedaluarsa.
Meskipun properti secara teknis sangat mirip dengan metode, mereka sangat berbeda dalam hal skenario penggunaannya. Mereka harus dianggap sebagai bidang cerdas. Mereka memiliki sintaks panggilan bidang, dan fleksibilitas metode.
✔️ BUAT properti get-only jika pemanggil tidak dapat mengubah nilai properti.
Perlu diingat bahwa jika jenis properti adalah jenis referensi yang dapat berubah, nilai properti dapat diubah bahkan jika properti merupakan get-only.
❌ JANGAN sediakan properti set-only atau properti dengan setter yang memiliki aksesibilitas lebih luas daripada getter.
Misalnya, jangan gunakan properti dengan setter publik dan getter yang dilindungi.
Jika getter properti tidak dapat disediakan, terapkan fungsionalitas sebagai metode sebagai gantinya. Pertimbangkan untuk memulai nama metode dengan Set dan lanjutkan dengan nama yang akan Anda berikan ke properti. Misalnya, AppDomain memiliki metode yang disebut SetCachePath alih-alih memiliki properti set-only yang disebut CachePath.
✔️ BERIKAN nilai default yang masuk akal untuk semua properti, memastikan bahwa default tidak menyebabkan celah keamanan atau kode yang sangat tidak efisien.
✔️ IZINKAN properti untuk diatur dalam urutan apa pun bahkan jika ini menghasilkan status objek yang tidak valid sementara.
Umum untuk dua atau lebih properti menjadi saling terkait hingga titik di mana beberapa nilai dari satu properti mungkin tidak valid mengingat nilai properti lain pada objek yang sama. Dalam kasus seperti itu, pengecualian yang dihasilkan dari status tidak valid harus ditunda sampai properti yang saling terkait benar-benar digunakan bersama oleh objek.
✔️ PERTAHANKAN nilai sebelumnya jika setter properti memberikan pengecualian.
❌ HINDARI melemparkan pengecualian dari getter properti.
Getter properti harus berupa operasi sederhana dan tidak boleh memiliki prasyarat. Jika getter dapat memberikan pengecualian, itu mungkin harus didesain ulang untuk menjadi metode. Perhatikan bahwa aturan ini tidak berlaku untuk pengindeks, di mana kita mengharapkan pengecualian sebagai hasil dari memvalidasi argumen.
Desain Properti Terindeks
Properti yang diindeks adalah properti khusus yang dapat memiliki parameter dan dapat dipanggil dengan sintaksis khusus yang mirip dengan pengindeksan larik.
Properti yang diindeks sering disebut sebagai pengindeks. Pengindeks harus digunakan hanya di API yang menyediakan akses ke item dalam koleksi logis. Misalnya, sebuah string adalah kumpulan karakter, dan pengindeks pada System.String ditambahkan untuk mengakses karakternya.
✔️ PERTIMBANGKAN untuk menggunakan pengindeks untuk menyediakan akses ke data yang disimpan dalam larik internal.
✔️ PERTIMBANGKAN untuk menyediakan pengindeks pada jenis yang mewakili koleksi item.
❌ HINDARI menggunakan properti terindeks dengan lebih dari satu parameter.
Jika desain memerlukan beberapa parameter, pertimbangkan kembali apakah properti benar-benar mewakili pengakses untuk koleksi logis. Jika tidak, gunakan metode sebagai gantinya. Pertimbangkan untuk memulai nama metode dengan Get atau Set.
❌ HINDARI pengindeks dengan jenis parameter selain System.Int32, System.Int64, System.String, System.Object, atau enum.
Jika desain memerlukan jenis parameter lain, evaluasi kembali dengan cermat apakah API benar-benar mewakili pengakses untuk koleksi logis. Jika tidak, gunakan metode. Pertimbangkan untuk memulai nama metode dengan Get atau Set.
✔️ GUNAKAN nama Item untuk properti terindeks kecuali ada nama yang jelas lebih baik (misalnya, lihat properti Chars[] di System.String).
Di C#, pengindeks secara default bernama Item. IndexerNameAttribute dapat digunakan untuk menyesuaikan nama ini.
❌ JANGAN menyediakan pengindeks dan metode yang setara secara semantik.
❌ JANGAN menyediakan lebih dari satu keluarga pengindeks yang kelebihan beban dalam satu jenis.
Ini diberlakukan oleh pengompilasi C #.
❌ JANGAN gunakan properti terindeks nondefault.
Ini diberlakukan oleh pengompilasi C #.
Peristiwa Pemberitahuan Perubahan Properti
Terkadang berguna untuk menyediakan peristiwa yang memberi tahu pengguna tentang perubahan nilai properti. Misalnya, System.Windows.Forms.Control menaikkan peristiwa TextChanged setelah nilai propertinya Text berubah.
✔️ PERTIMBANGKAN untuk meningkatkan peristiwa pemberitahuan perubahan saat nilai properti di API tingkat tinggi (biasanya komponen desainer) dimodifikasi.
Jika ada skenario yang baik bagi pengguna untuk mengetahui kapan properti suatu objek berubah, objek harus menaikkan peristiwa pemberitahuan perubahan untuk properti tersebut.
Namun, kemungkinan kecil ini akan sepadan dengan nilai overhead-nya untuk menaikkan peristiwa semacam itu untuk API tingkat rendah seperti jenis atau koleksi dasar. Misalnya, List<T> tidak akan menaikkan peristiwa tersebut saat item baru ditambahkan ke daftar dan properti Count berubah.
✔️ PERTIMBANGKAN untuk menaikkan peristiwa pemberitahuan perubahan saat nilai properti berubah melalui paksaan eksternal.
Jika nilai properti berubah melalui paksaan eksternal (dengan cara selain memanggil metode pada objek), peristiwa penaikkan mengindikasikan kepada pengembang bahwa nilainya sedang berubah dan telah berubah. Contoh yang baik adalah properti Text kontrol kotak teks. Saat pengguna mengetikkan teks dalam TextBox, nilai properti secara otomatis berubah.
Portions © 2005, 2009 Microsoft Corporation. Semua hak dilindungi undang-undang.
Dicetak ulang dengan izin dari Pearson Education, Inc. dari Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition oleh Krzysztof Cwalina dan Brad Abrams, diterbitkan 22 Okt 2008 oleh Addison-Wesley Professional sebagai bagian dari Seri Pengembangan Microsoft Windows.