Bagaimana OOP berevolusi untuk memasukkan gagasan tentang Properti


11

Saya berasal dari latar belakang C ++ dan saya akan keluar C # dalam pekerjaan saya saat ini dan saya baru saja membaca banyak T&J tentang apa perbedaan antara bidang publik dan properti dan semua bolak-balik dalam variasi dan inkarnasi dari ini pertanyaan dasar (mis. posting SO ini dan semua pertanyaan terkait lainnya ). Semua pertanyaan tersebut dibahas dalam hal perbedaan praktis yang menerima begitu saja keberadaan sistem properti, tetapi saya pikir akan lebih baik untuk mendekati subjek ini dalam hal apa perancang semua bahasa yang memutuskan untuk mendukung properti pada awalnya. Tempat berpikir (lihat daftar di artikel Wikipedia di sini). Bagaimana OOP berkembang dari C ++ / Java untuk memperluas ke apa yang artikel Wikipedia dengan menarik mengidentifikasi sebagai jalan tengah antara metode dan data anggota:

"Yaitu, properti adalah perantara antara kode anggota (metode) dan data anggota (variabel instan) dari kelas, dan properti menyediakan tingkat enkapsulasi yang lebih tinggi daripada bidang publik."

MSDN menambahkan latar belakang lebih lanjut:

"Meskipun properti secara teknis sangat mirip dengan metode, mereka sangat berbeda dalam hal skenario penggunaannya. Mereka harus dilihat sebagai bidang cerdas. Mereka memiliki sintaks panggilan bidang, dan fleksibilitas metode."

Saya ingin tahu bagaimana sampai pada tingkat enkapsulasi tingkat menengah ini terbukti bermanfaat untuk pemrograman secara umum. Saya berasumsi konsep ini tidak hadir pada inkarnasi pertama bahasa pemrograman yang mengekspresikan paradigma OOP.


8
Fitur bahasa telanjang hanya gula sintaksis nyaman untuk metode pengambil dan penyetel. Apakah ada alasan yang lebih dalam di balik penafsiran dan terminologi, saya tidak tahu.

Dalam serangkaian pakar OO, judul pertanyaan Anda dapat memancing, dan dapat mengalihkan perhatian dari apa yang sebenarnya Anda tanyakan. Bukannya saya menganggap diri saya seorang ahli OO, saya hanya seorang "pengguna OO" selama beberapa tahun.
Doc Brown

Ini adalah kerelaan sintaksis yang saya lewatkan dari 'metode tanpa parameter' dengan Python ke C ++. BMI = bob.weight/sq(bob.height)berbunyi lebih baik tanpa ()IMO.
OJFord

Saya pikir properti dalam Visual Basic (non .net) asli, sebagai cara untuk mengkonfigurasi objek Active X (COM). Kisi properti pada alat ini mungkin ada hubungannya dengan adopsi properti dalam bahasa. Perhatikan bahwa Visual Basic asli tidak berorientasi objek dalam banyak hal, tetapi memiliki kemampuan untuk membuat sesuatu seperti kelas.
Frank Hileman

Melanjutkan: jendela properti adalah cara untuk mengkonfigurasi objek tanpa menulis kode. Itu disebut pengembangan RAD. Tautan ini berisi tangkapan layar jendela properti VB6: microsoft.com/mspress/books/WW/sampchap/4068.aspx
Frank Hileman

Jawaban:


5

Ini semua tentang Enkapsulasi dan Prinsip Akses Seragam.

Objek harus dapat menanggapi pesan dengan mengembalikan data yang ada atau menjalankan metode, tetapi pengirim tidak dapat mengetahui yang mana. Atau jika Anda melihat ini dari sisi pengirim: pengirim harus dapat mengakses data yang ada atau menjalankan metode melalui antarmuka yang seragam.

Ada beberapa cara untuk mencapai ini:

  • singkirkan data sama sekali, cukup metode (Newspeak melakukan ini)

    • bentuk yang kurang radikal dari hal di atas: singkirkan data di antarmuka publik , yaitu buat data selalu pribadi, di antarmuka publik, hanya metode paparan (Smalltalk, Ruby melakukan ini)
  • singkirkan metode sama sekali, hanya punya data (Self melakukan ini, "metode" hanyalah Methodobjek yang ditugaskan ke variabel instan, variabel instan dilihat dengan pengiriman virtual)

  • tidak membuat perbedaan sintaksis atau semantik antara metode dan data (Scala melakukan ini, mengakses suatu bidang secara sintaktis tidak dapat dibedakan dari memanggil metode tanpa daftar argumen ( foo.bar), menugaskan ke suatu bidang secara sintaktis tidak dapat dibedakan dari memanggil metode yang dinamai secara khusus ( foo.bar = baz) adalah sama seperti foo.bar_=(baz)memanggil metode yang dinamai foo_=, dan nilai read-only dapat diganti atau diimplementasikan oleh metode tanpa daftar parameter (yaitu val foo) dalam superclass dapat diganti (atau abstract valdiimplementasikan) dalam subkelas dengan metode def foo)

Java, bagaimanapun, tidak mengikuti Prinsip Akses Seragam. Di Jawa, dimungkinkan untuk membedakan antara mengakses data dan menjalankan metode. foo.barberbeda dari foo.bar(). Alasan untuk ini adalah bahwa bidang dan metode berbeda secara semantik dan sintaksis.

C # mencoba untuk memperbaikinya dengan menambahkan properti ke bahasa, pada dasarnya metode yang terlihat seperti bidang. Namun, panggilan metode masih terlihat dan terasa berbeda dari akses bidang dan properti. Bidang dan properti sekarang memiliki Akses Seragam, tetapi metode tetap tidak.

Jadi, ini sebenarnya tidak memperbaiki masalah: Anda tidak dapat memperbaiki memiliki dua cara berbeda untuk mengakses sesuatu dengan menambahkan cara ketiga untuk mengakses sesuatu! Bahkan jika cara ketiga itu terlihat seperti salah satu dari dua cara lainnya, Anda masih akan memiliki (setidaknya) dua cara yang berbeda. Anda hanya dapat memperbaikinya dengan menyingkirkan semua cara yang berbeda kecuali satu atau menyingkirkan perbedaan.

Tidak masalah memiliki bahasa dengan metode, properti, dan bidang, tetapi ketiganya harus memiliki akses yang seragam.


1
Mengapa Anda (dan orang lain) menganggap menjaga Akses Seragam sangat penting? Dengan metode, Anda mungkin ingin memberinya parameter untuk mengubah apa yang dilakukan atau ditindaklanjuti. Dengan bidang atau properti yang Anda tidak memiliki kemampuan ini, Anda biasanya hanya mengembalikan data (meskipun properti dapat diimplementasikan sebagai menjalankan metode alih-alih hanya mengekspos bidang pribadi). Itu tampaknya intuitif bagi saya, mungkin hanya karena saya sudah terbiasa, tetapi apa yang akan Anda dapatkan dalam keanggunan atau produktivitas dengan menegakkan akses yang seragam? Apakah Anda khawatir Anda membocorkan detail implementasi di luar kelas?
Mike Mendukung Monica

1
UAP adalah tentang menjaga kebebasan untuk mengubah detail implementasi tanpa merusak antarmuka publik. Contoh yang biasa adalah menambahkan logging. Jika saya menawarkan akses melalui suatu metode, saya dapat dengan mudah mengubah internal metode untuk menulis ke log. Dengan bidang publik, saya tidak bisa menambahkan logging tanpa terlebih dahulu mengubahnya menjadi metode, yang memecah semua kode klien. Jika melanggar perubahan tidak bisa dipertaruhkan, menggunakan metode adalah suatu keharusan. Properti adalah kompromi yang optimal karena mereka adalah metode penuh tetapi terlihat seperti bidang. Mematuhi UAP meningkatkan enkapsulasi dan mengurangi kopling ketat.
amon

Banyak jawaban bagus untuk pertanyaan ini, tetapi saya pikir yang satu ini tepat dengan menarik keluar aspek yang lebih mendasar dari sifat bahasa pemrograman dan menguraikan tentang konsep formal yang relevan dari UAP. Solid
jxramos

18

Yah, saya tidak 100% yakin, tapi saya kira segalanya mungkin lebih sederhana dari yang Anda harapkan. Dari sekolah pemodelan OO tahun 90-an, ada permintaan untuk kelas pemodelan dengan atribut anggota yang dienkapsulasi, dan ketika diimplementasikan dalam bahasa seperti C ++ atau Java, ini biasanya mengarah ke kode dengan banyak getter dan setter, sehingga banyak "noise" kode untuk persyaratan yang relatif sederhana. Perhatikan bahwa sebagian besar (mungkin semua, tidak memeriksa ini) bahasa yang tercantum dalam artikel Wikipedia Anda yang terhubung mulai memperkenalkan "properti" objek pada akhir 90-an atau lebih baru.

Saya kira itu adalah alasan utama perancang bahasa memutuskan untuk menambahkan beberapa gula sintaksis untuk mengurangi kebisingan itu. Dan meskipun properti pasti bukan "konsep inti OO", mereka setidaknya ada hubungannya dengan orientasi objek. Mereka tidak menunjukkan "evolusi OOP" (seperti yang diasumsikan oleh judul pertanyaan Anda), tetapi mereka mendukung pemodelan OO di tingkat bahasa pemrograman untuk membuat implementasi lebih mudah.


Ini tidak ada hubungannya dengan pemrograman berorientasi objek, kecuali dalam arti bahwa properti adalah abstraksi dari suatu bidang, dan bidang adalah bagian dari pemrograman berorientasi objek. Tetapi properti tidak diperlukan untuk pemrograman berorientasi objek, seperti yang Anda catat dengan benar.
Frank Hileman

2
@ Frankhileman: "properti adalah abstraksi dari suatu bidang, dan bidang adalah bagian dari pemrograman berorientasi objek" - yah, itu kedengarannya seperti Anda setuju konsep itu sebenarnya setidaknya ada hubungannya dengan OOP. Dan itu sebabnya Anda menurunkan saya?
Doc Brown

3
lol. Bisakah kamu menyalahkannya? Dia melepas toiletnya dan membenturkan kepalanya ke wastafel. Ngomong-ngomong ... Cara saya selalu melihatnya adalah bahwa properti tidak sepenuhnya pada masalah OO. Mereka membantu dengan enkapsulasi dan enkapsulasi membantu dengan OO.
MetaFight

1
Ha! Ini cukup pengantar untuk programmer .stackexchange bagi saya. Lol, jauh lebih panas daripada pengalaman saya yang setara di stackoverflow polos :-p Cara yang baik untuk mencampur hari!
jxramos


11

Anda memilikinya mundur (semacam). Lambda Calculus hadir sebagai dasar formal inti untuk bahasa pemrograman, dan telah berlangsung selama beberapa dekade. Tidak memiliki bidang.

Untuk memodelkan keadaan yang bisa berubah, Anda perlu membuat dua abstraksi. Satu mewakili pengaturan beberapa negara, dan yang lain mengambil keadaan itu (Bab 13 dalam versi TaPL saya untuk referensi). Terdengar akrab? Dari latar belakang teoritis , OO tidak berevolusi untuk memiliki barang-barang ini. OO membaca Bahasa Pemrograman 101 dan membuat bayi melangkah maju.

Dari perspektif praktis , ada dua motivasi yang cukup jelas. Anda berasal dari latar belakang C ++, jadi apa yang perlu terjadi jika Anda memiliki bidang publik - katakanlah ... teks dalam kotak teks. Apa yang terjadi ketika Anda ingin mengubah desain Anda sehingga "setiap kali kotak teks ini berubah, lakukan bla"? Anda bisa mematikan bidang itu, membuat satu atau dua fungsi dan memasang logika itu, karena Anda tidak dapat mempercayai pengembang untuk memanggil "UpdateTextbox" sendiri. Ini adalah perubahan yang sangat melanggar untuk api Anda (dan sayangnya masih merupakan perubahan besar dalam implementasi properti .NET). Perilaku semacam ini ada di semua tempat di API Windows. Karena itu masalah besar di Microsoft, C # sepertinya ingin membuatnya lebih tidak menyakitkan.

Motivasi besar lainnya adalah Kacang Jawa dan kerabat mereka. Sejumlah kerangka kerja dibangun untuk menggunakan refleksi Jawa untuk mencari GetXdan SetXmemasangkan dan secara efektif memperlakukannya seperti properti modern. Tetapi karena mereka bukan konstruksi bahasa yang sebenarnya, kerangka kerja ini rapuh dan tidak berat. Jika Anda mengetik nama, hal-hal hanya akan pecah secara diam-diam. Jika ada yang refactored, tidak ada yang memindahkan sisi lain dari properti. Dan melakukan semua bidang / dapatkan / set boilerplate adalah verbose dan membosankan (bahkan untuk Java!). Karena C # sebagian besar dikembangkan sebagai "Jawa dengan pelajaran yang dipetik", rasa sakit semacam itu adalah salah satu pelajaran itu.

Tetapi hal terbesar adalah bahwa konsep properti telah berhasil. Mudah dimengerti, mudah digunakan. Ini sangat membantu adopsi, dan sebagai alat , programmer telah menemukan bahwa properti memecahkan subset masalah lebih bersih daripada fungsi atau bidang.


7
Saya menurunkan Anda sebagian besar untuk referensi terlalu banyak untuk omong kosong formal yang tidak relevan. Implementasi aktual dari bahasa pemrograman memiliki banyak hal yang lebih serius untuk dipertimbangkan daripada apakah model mereka dimasukkan dalam kalkulus lambda atau tidak.
DeadMG

9
@DeadMG - itu memang benar, tetapi di sisi lain pelaksana bahasa pemrograman akan selalu terbiasa dengan omong kosong formal yang tidak relevan . Berpikir bahwa itu tidak berdampak pada desain mereka adalah naif.
Telastyn

3
Ini jelas bukan "omong kosong formal yang tidak relevan." Namun, kalkulus lambda mungkin tidak dianggap banyak untuk bahasa pemrograman awal. Jika demikian, CPU mungkin akan lebih berorientasi pada mentalitas itu.
Frank Hileman

3
@ FrankHileman - Saya cukup yakin Lisp mempertimbangkannya ...
Telastyn

4
@ Telastyn - ya - dan Lisp awalnya tidak seharusnya menjadi bahasa pemrograman, ingat?
Frank Hileman

3

Dalam .net khusus, properti berasal dari hari-hari Visual Basic lama yang seperti itu tidak berorientasi objek seperti yang kita pikirkan hari ini. Itu sebagian besar dibangun di sekitar sistem COM baru yang secara dangkal memperlakukan segala sesuatu tidak harus sebagai kelas tetapi dalam hal komponen yang akan mengekspos properti yang dapat diakses baik dalam kode tetapi juga dalam editor grafis. Ketika VB dan C # yang baru dibuat digabungkan ke .net, VB memperoleh banyak fitur OOP dan mereka menyimpan properti karena menghapusnya akan seperti langkah mundur - bayangkan jika alat pembaruan kode otomatis yang mereka miliki di Visual Studio telah mengganti semua properti Anda dengan getter dan setter dan melanggar kompatibilitas dengan semua perpustakaan-COM. Akan logis untuk mendukung mereka semua.


Saya tidak berpikir Anda harus mengabaikan keturunan C # yang berasal dari Delphi dan dari sebelumnya, Object Pascal dan Turbo Pascal dengan Objects. Ini berorientasi objek dan memang memiliki properti (meskipun saya tidak ingat apakah OP memiliki properti dari TP5.5 atau apakah mereka ditambahkan; mungkin mereka diteruskan ke C # oleh Anders karena mereka secara pragmatis ide yang bagus.
Amaca

Sangat menarik bahwa Anda kebetulan adalah satu-satunya yang mendapat aspek komponen untuk pertanyaan ini. Saya baru saja menambahkan komentar ke pertanyaan saya yang menghubungkan ke situs yang mendaftarkan properti sebagai bagian dari beberapa model properti-metode-peristiwa yang memenuhi C #. Saya kemudian mencari halaman "pertanyaan" saya lagi untuk "komponen" mendarat beberapa positif palsu tetapi jawaban Anda saya pikir sebenarnya tumpang tindih dengan apa yang saya tautkan.
jxramos

3

Properti tidak ada hubungannya dengan pemrograman berorientasi objek, karena sifat hanya gula sintaksis. Properti terlihat seperti bidang secara dangkal, dan di dunia .net, disarankan bahwa mereka berperilaku seperti bidang dalam beberapa hal, tetapi mereka bukan bidang dalam arti apa pun. Properti adalah gula sintaksis untuk satu atau dua metode: satu untuk mendapatkan nilai, dan satu untuk menetapkan nilai. Metode set atau metode get mungkin dihilangkan, tetapi tidak keduanya. Mungkin tidak ada bidang yang menyimpan nilai yang dikembalikan oleh metode get. Karena mereka berbagi sintaks dengan bidang, dan karena mereka sering menggunakan bidang, orang mengaitkan properti dengan bidang.

Properti memiliki keunggulan dibandingkan bidang:

  • Dalam metode kumpulan properti, sebelum nilai properti disimpan, nilai baru, atau keadaan objek, dapat diperiksa terhadap serangkaian prasyarat atau invarian.
  • Metode properti get mungkin ada untuk kenyamanan, jika pengambilan nilai properti dapat secara logis dianggap setara dengan pengambilan nilai bidang.
  • Metode kumpulan properti dapat melakukan operasi lain, seperti memberi tahu objek induk atau mendengarkan objek perubahan ke nilai properti.

Karena properti adalah abstraksi bidang, dan untuk kenyamanan sintaksis, bahasa seperti C # mengadopsi sintaks bidang untuk properti.


2
Baris pertama dari artikel Wikipedia. "Properti, dalam beberapa bahasa pemrograman berorientasi objek, adalah jenis khusus anggota kelas ...". Jadi kalimat pertama Anda salah. Dan sisanya tidak menjawab pertanyaan.
Doc Brown

1
@DocBrown: Respons yang menarik. Banyak artikel Wikipedia jelas salah. Saya menganggap Anda membela penulis artikel khusus ini?
Frank Hileman

1
Tidak semua fitur bahasa pemrograman berorientasi objek terkait dengan konsep berorientasi objek.
Frank Hileman

1
Itu tidak mengubah fakta Anda tidak menjawab pertanyaan.
Doc Brown

3
Perlu dicatat bahwa bukan hanya setter yang opsional. Anda dapat memiliki properti setter saja.
Telastyn

2

Ini masalah implementasi versus implikasi . Properti berada di OOP sebelum C ++ atau Java mengenai tempat kejadian (mereka ada di sana, dengan beberapa kekasaran di sekitar, di Simula, dan mereka mendasar bagi Smalltalk). Entitas dengan properti secara konseptual berbeda dari nilai dengan kode yang dilampirkan. Awalan get & set dalam beberapa konvensi bahasa hanya berfungsi untuk memperkeruh perairan; mereka membuat Anda mengetahui perbedaan antara bidang dan properti, dengan asumsi bahwa bidang dapat diakses secara langsung tanpa mendapatkan / mengatur dengan cara yang idiomatis untuk bahasa, dan itu bocor.

Inti dari OOP adalah untuk memperlakukan hal-hal seolah-olah mereka adalah entitas di dunia "nyata", bukan hanya sebagai struct dengan beberapa kode yang bercampur. Pemrogram lain harus tahu, sangat sedikit tentang cara saya telah mengimplementasikan sesuatu, dan sama sekali tidak harus peduli dengan mana dari berbagai nilai yang mereka boleh dapatkan dan / atau atur adalah nyata dan mana yang virtual. Jika Anda menemukan vektor saya, Anda tidak perlu tahu apakah saya menyimpan sudut dan besarnya atau komponen nyata dan imajiner internal ke objek vektor. Jika saya mengubah representasi di V2.0 perpustakaan saya, itu tidak akan memengaruhi kode Anda sama sekali (meskipun Anda mungkin ingin memanfaatkan fitur-fitur baru yang keren). Demikian pula, ada properti yang mungkin dimiliki entitas yang bergantung pada data eksternal entitas, tetapi yang tidak diragukan lagi sifat dari sudut pandang leksikal. Anda bertanya kepada orang-orang "berapa umur Anda", bukan "tolong lakukan perhitungan yang akan mengungkapkan usia Anda kepada saya", meskipun Anda tahu bahwa data yang tersedia untuk "objek" itu adalah tanggal lahir (anggota tidak berubah pribadi) dan hari ini date (properti publik yang bertambah secara otomatis, bergantung pada zona waktu, waktu musim panas, dan Garis Tanggal Internasional). Umur adalah properti, bukan metode, meskipun dibutuhkan beberapa perhitungan untuk sampai ke sana dan tidak dapat (kecuali dalam representasi komputer mainan hal-hal dengan masa hidup yang terbatas secara artifisial) disimpan sebagai bidang. walaupun Anda tahu bahwa data yang tersedia untuk "objek" itu adalah tanggal lahir (anggota tidak berubah pribadi) dan tanggal hari ini (properti publik, properti lingkungan yang bertambah otomatis, bergantung pada zona waktu, waktu musim panas, dan Garis Tanggal Internasional ). Umur adalah properti, bukan metode, meskipun dibutuhkan beberapa perhitungan untuk sampai ke sana dan tidak dapat (kecuali dalam representasi komputer mainan hal-hal dengan masa hidup yang terbatas secara artifisial) disimpan sebagai bidang. walaupun Anda tahu bahwa data yang tersedia untuk "objek" itu adalah tanggal lahir (anggota tidak berubah pribadi) dan tanggal hari ini (properti publik, properti lingkungan yang bertambah otomatis, bergantung pada zona waktu, waktu musim panas, dan Garis Tanggal Internasional ). Umur adalah properti, bukan metode, meskipun dibutuhkan beberapa perhitungan untuk sampai ke sana dan tidak dapat (kecuali dalam representasi komputer mainan hal-hal dengan masa hidup yang terbatas secara artifisial) disimpan sebagai bidang.

Daripada memikirkan properti sebagai anak haram bidang dan metode, itu jauh lebih memuaskan untuk hal metode sebagai jenis properti khusus - hal-hal yang entitas Anda dapat lakukan daripada hal-hal yang mereka lakukan. Kalau tidak, Anda tidak berurusan dengan objek / entitas secara konseptual, Anda berhadapan dengan koleksi data yang memiliki kode yang melekat padanya. The implementaions mungkin identik, tetapi implikasi yang berbeda.

Seharusnya tidak perlu dikatakan, bahwa abstraksi ini harus dibayar mahal. Jika seorang programmer yang menggunakan kelas tidak dapat mengetahui apakah ia mengakses data seperti yang disimpan atau mendapatkan / menetapkan nilai-nilai yang perlu dihitung, maka akan ada tingkat di mana bahasa juga tentu tidak pasti (dan karena itu dapat mensyaratkan bahwa semuanya memerlukan kode untuk perantara antara accessors / penyeleksi dan nilai-nilai). Tidak ada yang salah secara konsep dengan "structs with code" - mereka pasti bisa jauh lebih efisien - tetapi mereka membocorkan implementasi di semua tempat, dan itulah salah satu hal yang seharusnya dihilangkan OOP.


Saya setuju dengan beberapa poin dan tidak setuju dengan orang lain, tetapi pesan secara keseluruhan adalah satu yang baik: Beberapa informasi tentang kebutuhan objek yang akan dihitung namun masih secara teknis informasi yang adalah bukan suatu tindakan yang dapat dilakukan .
Pharap

0

Sama sekali tidak ada. Properti dan OOP tidak ada hubungannya satu sama lain. Properti tidak lebih dari gula sintaksis untuk pemanggilan fungsi, dan oleh karena itu memiliki keterikatan OOP yang persis sama dengan pemanggilan fungsi — artinya, tidak ada.

Ngomong-ngomong Wikipedia benar-benar salah. Pola getMember / setMember yang Anda lihat di Java menawarkan keuntungan (dan kerugian) yang persis sama dengan properti di C #. Dan Anda dapat meniru pola ini bahkan dalam C jika Anda mau.

Properti dalam C # tidak lebih dari sintaksis yang didukung bahasa.


3
Pernahkah Anda melihat konsep properti dalam bahasa pemrograman apa pun di luar konteks kelas atau objek? Aku belum.
Doc Brown

1
@DocBrown: Saya sudah menerapkannya. Faktanya adalah, properti adalah target bernilai cukup rendah untuk penulis bahasa, karena peningkatan mereka atas panggilan fungsi biasa rendah.
DeadMG

1
OP bertanya tentang sejarah properti sebagai konsep dalam bahasa pemrograman populer. Dan sebenarnya, dalam arti historis ada hubungan antara properti dan OOP.
Doc Brown

2
Mungkin saya agak terburu-buru untuk menganggap konsep properti ini dengan paradigma OOP sendiri, tetapi sebagai konsep tentu saja melampaui bahasa individu dan fitur-fiturnya. Mungkin saya sedang berjuang untuk mengartikulasikan ontologi yang tepat di antara keduanya. Saya tidak menyarankan melalui judul pertanyaan bahwa properti adalah fitur / konsep mendasar dari OOP yang membuat atau menghancurkan formalisme OOP, namun saya rasa mereka hanya memiliki kenyataan di ruang OOP ini, itulah sebabnya saya mengatakan pertanyaan seperti itu. .
jxramos

4
Mereka bukan hanya sintaksis gula dalam C #, mereka ada dalam metadata rakitan sebagai anggota berbeda dan Anda dapat melakukan hal-hal dengan properti yang tidak dapat Anda gunakan dengan bidang, seperti penyatuan data.
Andy
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.