Perbedaan antara Desain dengan Kontrak dan Pemrograman Defensive

Bisakah Designing by Contract (DbC) menjadi cara memprogram secara defensif?

Apakah satu cara pemrograman lebih baik dalam beberapa kasus daripada yang lain?

design-patterns contract defensive-programming

— Gabriel Fair
sumber

Jawaban:

Desain oleh Kontrak dan pemrograman defensif dalam beberapa hal bertentangan satu sama lain: di DbC, Anda mendefinisikan kontrak antara kolaborator dan Anda memprogram dengan asumsi bahwa kolaborator menghormati kontrak mereka. Dalam pemrograman defensif, Anda memprogram dengan asumsi bahwa kolaborator Anda melanggar kontrak mereka.

Rutin akar kuadrat nyata yang ditulis dalam gaya DbC akan menyatakan dalam kontraknya bahwa Anda tidak diizinkan untuk melewati angka negatif dan kemudian hanya berasumsi bahwa itu tidak pernah dapat menemukan angka negatif. Rutin root kuadrat nyata ditulis defensif akan menganggap bahwa itu melewati angka negatif dan mengambil tindakan pencegahan yang tepat.

Catatan: tentu saja mungkin bahwa di DbC orang lain akan memeriksa kontrak. Di Eiffel, misalnya, sistem kontrak akan memeriksa angka negatif pada saat runtime dan melemparkan pengecualian yang sesuai. Dalam Spec #, pembalas teorema akan memeriksa angka negatif pada waktu kompilasi dan gagal membangun, jika tidak dapat membuktikan bahwa rutin tidak akan pernah melewati angka negatif. Perbedaannya adalah bahwa programmer tidak melakukan pemeriksaan ini.

— Jörg W Mittag
sumber

Bisakah Designing by Contract (DbC) menjadi cara memprogram secara defensif?

Iya nih.

"Pemrograman Defensif" seringkali menjadi alasan untuk membuang waktu. Sering buang waktu memeriksa hal-hal yang akan menyebabkan pengecualian biasa. Alih-alih pengecualian, pernyataan IF tambahan ditulis alih-alih klausa penanganan pengecualian.

Definisikan kontrak dan selesaikan dengan itu.

Ketika seseorang melanggar kontrak, program akan - dalam peristiwa normal - istirahat dan meningkatkan pengecualian normal yang biasanya dapat ditangani.

"Pemrograman defensif" dan "Pencegahan kesalahan" dapat ditampilkan untuk menambah kesalahan (karena pemeriksaan pencegahan kesalahan itu sendiri salah) daripada mencegah kesalahan.

Penanganan pengecualian dapat membungkam, mencatat dan menangani pengecualian jauh lebih baik daripada "Pemrograman Defensif".

— S.Lott
sumber

Pemrograman defensif adalah moe dari sekadar pernyataan. Ini termasuk ulasan kode, analisis statis, audit keamanan, pedoman pengkodean aman, dan banyak lagi. Selain itu, penggunaan eksepsi dan penanganan eksepsi (bukan hanya membiarkan program crash dan burn) dianggap sebagai teknik pemrograman defensif.

— Thomas Owens

@ThomasOwens: Kedengarannya seperti "Pengembangan Perangkat Lunak yang Baik". Saya hanya pernah melihat pemrograman defensif digunakan sebagai alasan untuk menulis banyak pernyataan IF (atau pernyataan) yang gagal sebelum pengecualian biasanya dimunculkan. Saya tidak akan menyebut daftar panjang ide bagus Anda "Pemrograman Defensif". Saya akan menyebut daftar ide bagus Anda "Pemrograman". Dengan begitu kita dapat memisahkan pemborosan waktu dari semua hal cerdas yang Anda daftarkan.

— S.Lott

Saya lebih suka menyebut "ide-ide bagus saat menulis kode" sendiri, tetapi ketika saya diajarkan tentang pemrograman defensif, saya diajari bahwa itu merujuk pada setiap dan semua teknik dengan tujuan yang jelas untuk memastikan keselamatan, keamanan, dan keandalan suatu sistem. . Mungkin itu definisi yang terlalu luas, atau mungkin itu definisi yang salah, tetapi itulah yang diajarkan kepada saya. Saya telah melihat orang-orang menyebut pernyataan dan pernyataan "pemrograman defensif", tetapi berdasarkan definisi yang saya ajarkan, saya tidak akan menyebutnya seperti itu (kecuali jika Anda tidak memiliki opsi yang lebih baik, seperti pengecualian).

— Thomas Owens

@ThomasOwens: "Mungkin itu definisi yang terlalu luas". Setuju. Sepertinya daftar periksa ide bagus yang bagus.

— S.Lott

-1: Saya tidak melihat bagaimana DbC adalah cara memprogram pertahanan, mereka pada dasarnya bertentangan. Saya ragu itu biasa untuk melakukan pemrograman defensif hanya untuk membuang waktu. Dan 'dapat ditunjukkan untuk menambah kesalahan' perlu kutipan karena sama sekali tidak jelas.

— Markus