Sự khác biệt giữa Thiết kế theo Hợp đồng và Lập trình phòng thủ

Thiết kế theo hợp đồng (DbC) có thể là một cách để lập trình phòng thủ?

Là một cách lập trình tốt hơn trong một số trường hợp so với cách khác?

design-patterns contract defensive-programming

Câu trả lời:

Thiết kế theo Hợp đồng và lập trình phòng thủ theo một số ý nghĩa trái ngược nhau: trong DbC, bạn xác định hợp đồng giữa các cộng tác viên và bạn lập trình theo giả định rằng các cộng tác viên tôn trọng hợp đồng của họ. Trong lập trình phòng thủ, bạn lập trình theo giả định rằng các cộng tác viên của bạn vi phạm hợp đồng của họ.

Một thói quen căn bậc hai thực sự được viết theo kiểu DbC sẽ nêu trong hợp đồng của nó rằng bạn không được phép chuyển số âm và sau đó chỉ cần giả định rằng nó không bao giờ có thể gặp số âm. Một thói quen căn bậc hai thực sự được viết một cách phòng thủ sẽ cho rằng nó được thông qua một số âm và có biện pháp phòng ngừa thích hợp.

Lưu ý: tất nhiên có thể là trong DbC sẽ có người khác kiểm tra hợp đồng. Ví dụ, tại Eiffel, hệ thống hợp đồng sẽ kiểm tra số âm trong thời gian chạy và đưa ra một ngoại lệ thích hợp. Trong Spec #, người cung cấp định lý sẽ kiểm tra các số âm tại thời điểm biên dịch và không xây dựng được, nếu điều đó không thể chứng minh rằng thói quen sẽ không bao giờ vượt qua số âm. Sự khác biệt là lập trình viên không thực hiện kiểm tra này.

— Jorg W Găngag
nguồn

Thiết kế theo hợp đồng (DbC) có thể là một cách để lập trình phòng thủ?

Vâng.

"Lập trình phòng thủ" thường là một cái cớ để lãng phí thời gian. Nó thường lãng phí thời gian để kiểm tra những thứ sẽ gây ra ngoại lệ thông thường. Thay vì các trường hợp ngoại lệ, các câu lệnh IF bổ sung được viết thay vì các mệnh đề xử lý ngoại lệ.

Xác định hợp đồng và được thực hiện với nó.

Khi ai đó vi phạm hợp đồng, chương trình sẽ - trong quá trình bình thường của sự kiện - phá vỡ và đưa ra các ngoại lệ bình thường có thể được xử lý thông thường.

"Lập trình phòng thủ" và "Ngăn ngừa lỗi" có thể được hiển thị để thêm lỗi (vì bản thân các kiểm tra phòng ngừa lỗi là sai) thay vì ngăn ngừa lỗi.

Xử lý ngoại lệ có thể làm im lặng, ghi nhật ký và xử lý một ngoại lệ tốt hơn nhiều so với "Lập trình phòng thủ".

— S.Lott
nguồn

Lập trình phòng thủ là moe hơn chỉ là nếu tuyên bố. Nó bao gồm đánh giá mã, phân tích tĩnh, kiểm toán bảo mật, hướng dẫn mã hóa an toàn, v.v. Ngoài ra, việc sử dụng các trường hợp ngoại lệ và xử lý ngoại lệ (trái ngược với việc đơn giản là để chương trình bị sập và cháy) được coi là một kỹ thuật lập trình phòng thủ.

— Thomas Owens

@ThomasOwens: Nghe có vẻ như "Phát triển phần mềm tốt". Tôi chỉ từng thấy lập trình phòng thủ được sử dụng như một cái cớ để viết rất nhiều câu lệnh IF (hoặc xác nhận) thất bại trước khi các ngoại lệ thường được nêu ra. Tôi sẽ không gọi danh sách dài các ý tưởng thực sự hay của bạn là "Lập trình phòng thủ". Tôi sẽ gọi danh sách các ý tưởng hay của bạn là "Lập trình". Bằng cách đó, chúng ta có thể tách thời gian lãng phí khỏi tất cả những điều thông minh mà bạn liệt kê.

— S.Lott

Tôi thích tự gọi những "ý tưởng tốt khi viết mã", nhưng khi tôi được dạy về lập trình phòng thủ, tôi được dạy rằng nó đề cập đến bất kỳ và tất cả các kỹ thuật với mục đích rõ ràng là đảm bảo an toàn, bảo mật và độ tin cậy của hệ thống . Có thể đó là một định nghĩa quá rộng, hoặc có lẽ đó là một định nghĩa sai, nhưng đó là những gì tôi được dạy. Tôi đã thấy mọi người gọi nếu tuyên bố và khẳng định là "lập trình phòng thủ", nhưng dựa trên định nghĩa tôi được dạy, tôi sẽ không gọi nó như vậy (trừ trường hợp bạn không nhất thiết phải có lựa chọn tốt hơn, như ngoại lệ).

— Thomas Owens

@ThomasOwens: "Có thể đó là một định nghĩa quá rộng". Đồng ý. Có vẻ như một danh sách kiểm tra tuyệt vời của những ý tưởng tốt.

— S.Lott

-1: Tôi không thấy DbC là một cách để lập trình phòng thủ, về cơ bản chúng đối lập nhau. Tôi nghi ngờ việc lập trình phòng thủ chỉ để lãng phí thời gian là điều phổ biến. Và 'có thể được hiển thị để thêm lỗi' cần một trích dẫn vì nó hoàn toàn không rõ ràng.

— Đánh dấu