Perdebatan yang semakin berkembang dalam komuniti pengaturcaraan berpusat pada kelemahan asas dalam cara bahasa pengaturcaraan moden mengendalikan jenis maklumat yang berbeza. Perbincangan ini menyerlahkan bagaimana bahasa memaksa pembangun ke dalam kompromi yang janggal apabila mewakili data mudah berbanding objek kompleks dengan tingkah laku.
Isu teras berpunca daripada bahasa yang menganggap segala-galanya dengan cara yang sama, sama ada ia nombor mudah yang tidak pernah berubah atau komponen sistem kompleks yang mengekalkan keadaan sepanjang masa. Pendekatan satu-saiz-untuk-semua ini mewujudkan kerumitan yang tidak perlu dan membawa kepada keputusan seni bina yang lemah di seluruh industri perisian.
Kisah Dua Paradigma Pengaturcaraan
Komuniti pengaturcaraan telah mengenal pasti dua pendekatan berbeza yang cenderung disukai oleh bahasa. Bahasa berorientasikan objek seperti Java menolak segala-galanya ke dalam objek, malah nilai mudah seperti nombor. Ini mewujudkan overhed dan kerumitan di mana tidak sepatutnya wujud. Sebaliknya, bahasa fungsional seperti Haskell cemerlang dalam mengendalikan data tulen tetapi bergelut apabila anda memerlukan komponen berkeadaan yang mengekalkan identiti sepanjang masa.
Perbincangan komuniti mendedahkan bahawa C# telah membuat kemajuan ketara dalam menangani perpecahan ini. Tidak seperti Java , C# membezakan antara jenis nilai (structs) untuk data mudah dan jenis rujukan (classes) untuk objek dengan identiti. Pilihan reka bentuk ini, yang hadir sejak versi pertama bahasa, membolehkan pembangun membuat keputusan sedar tentang bagaimana data mereka sepatutnya berkelakuan.
Pendekatan Bahasa terhadap Perbezaan Data/Objek
- C: Pemisahan yang jelas dengan jenis nilai (structs) berbanding jenis rujukan (classes) sejak versi 1
- Java: Pendekatan segala-sebagai-objek, perlahan-lahan menambah jenis nilai melalui Project Valhalla
- Haskell: Sokongan data yang kuat dengan jenis algebra, keupayaan seperti objek yang terhad
- Scala: Kelas kes cuba merapatkan jurang antara data dan objek
- Erlang / Elixir: Asas data tidak berubah yang kukuh dengan simulasi objek berasaskan proses
- Rust: Cuba menyediakan kedua-dua keselamatan dan prestasi dengan peningkatan kerumitan
Kesan Dunia Sebenar Terhadap Seni Bina Sistem
Kekeliruan antara data dan objek telah mempengaruhi trend teknologi utama dengan cara yang tidak dijangka. Pergerakan NoSQL mendapat daya tarikan sebahagiannya kerana pangkalan data tradisional bergelut dengan struktur data seperti pokok, memaksa pembangun untuk mengatasi kekangan hubungan. Begitu juga, REST API menjadi popular kerana ia membolehkan sistem bertukar data sebenar sebagai JSON , dan bukannya berurusan dengan kerumitan pendekatan berorientasikan objek SOAP .
Saya tidak menyalahkan sesiapa kerana sedikit kegembiraan yang tidak rasional selepas dibebaskan daripada kekangan itu. Ia sangat membebaskan untuk menyimpan data, bukan?
Komuniti menunjukkan bahawa banyak masalah seni bina perkhidmatan berpunca daripada kekeliruan asas ini. Pembangun sering mencipta perkhidmatan yang hanya mengocok data dan bukannya menyediakan tingkah laku yang bermakna, membawa kepada anti-pattern berterusan perkhidmatan CRUD yang telah cuba dihapuskan oleh perunding selama lebih sedekad.
Pertimbangan Prestasi dan Praktikal
Perdebatan meluas kepada implikasi prestasi juga. Struktur data tidak berubah, yang disukai oleh penyokong pengaturcaraan fungsional, menyediakan jaminan keselamatan dan berfungsi dengan baik dalam persekitaran berbilang benang. Walau bagaimanapun, ia datang dengan kos prestasi berbanding mutasi di tempat yang digunakan dalam senario prestasi tinggi seperti sistem perdagangan dan enjin permainan.
Bahasa seperti Erlang dan Elixir menunjukkan faedah asas yang kukuh dengan data tidak berubah, tetapi mereka kekurangan sistem jenis statik yang dianggap penting oleh ramai pembangun untuk projek berskala besar. Sementara itu, bahasa yang lebih baru seperti Rust cuba menyediakan kedua-dua keselamatan dan prestasi, walaupun dengan peningkatan kerumitan yang mesti dikuasai oleh pembangun.
Perbandingan Ciri-ciri Data vs Objek
| Aspek | Data | Objek |
|---|---|---|
| Kesamaan | Berasaskan nilai: mana-mana 1 sama dengan 1 | Berasaskan identiti: 1 ini ≠ 1 itu |
| Penyalinan | Salin dengan bebas, hanya bait | Pensirilan mencipta identiti baharu |
| Kebolehubahan | Tidak boleh diubah secara semula jadi | Biasanya boleh diubah untuk pengurusan keadaan |
| Dalaman | Terdedah, mematuhi skema | Terkapsul dengan akses terkawal |
| Kebolehkembangan | Varian tetap, fungsi tidak terhad | Operasi tetap, varian boleh dikembangkan |
Jalan Ke Hadapan
Komuniti pengaturcaraan semakin mengiktiraf bahawa reka bentuk bahasa masa depan sepatutnya menyokong kedua-dua paradigma secara eksplisit dan bukannya memaksa segala-galanya ke dalam satu model. Pembangun memerlukan alat yang membolehkan mereka secara sedar memilih antara mewakili sesuatu sebagai data tulen atau sebagai objek dengan tingkah laku dan identiti.
Sesetengah bahasa berkembang ke arah ini. Java perlahan-lahan menambah jenis nilai melalui Project Valhalla , manakala case classes Scala menyediakan jalan tengah antara data tulen dan objek penuh. Walau bagaimanapun, penyelesaian ini sering terasa seperti tampung pada sistem sedia ada dan bukannya prinsip reka bentuk asas.
Perbincangan mencadangkan bahawa reka bentuk bahasa pengaturcaraan yang lebih baik boleh mencegah banyak masalah seni bina dengan menjadikan pilihan data-berbanding-objek eksplisit dan menyokong kedua-dua corak dengan sama baik. Ini akan membantu pembangun membuat keputusan reka bentuk yang lebih sedar dan mengelakkan kekeliruan yang kini melanda seni bina perisian.
Rujukan: Data, objects, and how we're railroaded into poor design