Contoh Perubahan yang Tidak Kompatibel

Saat berhadapan dengan perubahan yang tidak kompatibel, aturan praktis yang tidak menguntungkan adalah sebagai berikut: setiap perubahan dapat menjadi tidak kompatibel mundur, kecuali jika dipahami dengan sangat baik. Aturan ini membutuhkan pengetahuan tentang aturan NDR. Jika Anda tidak tahu apa itu NDR, jangan melakukan modifikasi. Contoh perubahan yang biasanya mengakibatkan pelanggaran akses dalam aplikasi, atau BAD_STUB_DATA_EXCEPTION yang dibesarkan oleh mesin marshaling, adalah sebagai berikut:

• Menambahkan metode baru di tengah metode lama.
• Menambahkan atau menghapus parameter dari metode.
• Mengubah atribut, misalnya atribut pointer: mengubah [ref] menjadi [unique] atau [ptr] atau sebaliknya. Setiap jenis pointer memiliki representasi kawat yang berbeda.
• Mengubah ukuran data: dari pendek ke panjang, dari karakter ke wchar_t (unicode), menambahkan bidang ke struktur, mengubah ukuran array ukuran tetap.
• Menambahkan lengan serikat ke serikat dengan klausul default.

Beberapa perubahan berbahaya atau ketidakcocokan yang tidak diinginkan antara klien dan server dapat terjadi sebagai berikut:

• Memodifikasi anggota jenis majemuk, seperti struktur atau array. Misalnya, jika CLIENT_ID berubah dari integral ke GUID, struktur CLIENT_RECORD dengan bidang CLIENT_ID menjadi tidak kompatibel. Ini mungkin sulit dideteksi jika dikaskade melalui beberapa tingkat penyematan ke jenis parameter jarak jauh yang sebenarnya.
• Mengubah jenis yang diimpor. Jenisnya mungkin berasal dari komponen berbeda yang tidak jarak jauh secara langsung, oleh karena itu perubahan dianggap kompatibel.
• Menggunakan #ifdef dalam file IDL adalah ide buruk untuk definisi jenis ifdef dalam file IDL—itu adalah bencana yang menunggu untuk terjadi. Tak pelak, karena build atau gangguan lainnya, klien dikompilasi dengan sekumpulan definisi yang berbeda dari server, dan akhirnya tidak kompatibel.