계약 별 디자인과 방어 프로그래밍의 차이점


답변:


30

계약에 의한 설계와 방어 프로그래밍은 서로 상반됩니다. DbC에서는 공동 작업자 간의 계약을 정의하고 공동 작업자가 계약을 존중한다는 가정하에 프로그램을 작성합니다. 방어 프로그래밍에서는 공동 작업자 가 계약을 위반한다고 가정하여 프로그래밍합니다 .

DbC 스타일로 작성된 실제 제곱근 루틴은 계약에서 음수를 전달할 수 없으며 음수를 절대로 만날 수 없다고 가정합니다. 방어 적으로 작성된 실제 제곱근 루틴은 그것이 음수로 전달되고 적절한 예방 조치를 취한다고 가정합니다.

참고 : 물론 DbC에서는 다른 사람 이 계약을 확인할 수 있습니다. 예를 들어 Eiffel에서는 계약 시스템이 런타임에 음수를 확인하고 적절한 예외를 발생시킵니다. Spec #에서 정리 증명자는 컴파일 타임에 음수를 확인하고 루틴에 음수가 전달되지 않는다는 것을 증명할 수없는 경우 빌드에 실패합니다. 차이점은 프로그래머 가이 검사를하지 않는다는 것입니다.


7

계약에 의한 설계 (DbC)는 방어 적으로 프로그래밍하는 방법 일 수 있습니까?

예.

"방어 프로그래밍"은 종종 시간을 낭비하는 변명입니다. 일상적인 예외를 유발하는 것들을 검사하는 데 종종 시간을 낭비합니다. 예외 대신 예외 처리 절 대신 추가 IF 문이 작성됩니다.

계약을 정의하고 완료하십시오.

누군가가 계약을 위반하면 프로그램은 정상적인 이벤트 과정에서 정상적으로 처리 할 수있는 정상적인 예외를 해제하고 제기합니다.

"방어 프로그램"및 "오류 방지"는 오류를 방지하기보다는 오류를 추가하는 것으로 표시 될 수 있습니다 (오류 방지 검사 자체가 잘못 되었기 때문에).

예외 처리는 "방어 프로그래밍"보다 훨씬 더 나은 예외를 침묵, 기록 및 처리 할 수 ​​있습니다.


6
방어 프로그래밍은 if 문보다 더 중요합니다. 코드 검토, 정적 분석, 보안 감사, 보안 코딩 지침 등이 포함됩니다. 또한 예외 및 예외 처리 (프로그램 충돌 및 굽기와 반대) 사용은 방어 적 프로그래밍 기술로 간주됩니다.
— Thomas Owens

2
@ThomasOwens : "좋은 소프트웨어 개발"처럼 들립니다. 나는 예외가 정상적으로 제기되기 전에 실패하는 많은 IF 문 (또는 주장)을 작성하는 변명으로 사용되는 방어 프로그래밍을 본 적이 있습니다. 난 정말 좋은 아이디어의 긴 목록을 "방어 프로그래밍"이라고 부르지 않을 것이다. 좋은 아이디어 목록을 "프로그래밍"이라고 부릅니다. 그렇게하면 시간 낭비를 목록에있는 모든 똑똑한 것들과 분리 할 수 ​​있습니다.
— S.Lott

2
나는 "코드를 작성할 때 좋은 아이디어"라고 부르는 것을 선호하지만 방어 프로그래밍에 대해 배울 때 시스템의 안전, 보안 및 신뢰성을 보장하기 위해 모든 기술을 언급한다고 배웠습니다. . 어쩌면 그것은 지나치게 광범위한 정의이거나 어쩌면 잘못된 정의 일지 모르지만 그것은 내가 가르쳐 진 것입니다. 나는 사람들이 if 문과 어설 션을 "방어 프로그래밍"이라고 부르는 것을 보았지만, 내가 배운 정의에 따르면 그렇게 부르지 않을 것입니다 (예외와 같이 더 나은 옵션이 반드시 필요한 것은 아닙니다).
— Thomas Owens

@ThomasOwens : "아마도 그것은 매우 광범위한 정의"입니다. 동의하다. 좋은 아이디어에 대한 훌륭한 체크리스트처럼 보입니다.
— S.Lott

2
-1 : DbC가 방어 적으로 프로그래밍하는 방법을 모르겠습니다. 기본적으로 반대입니다. 나는 시간을 낭비하기 위해 방어 프로그래밍을하는 것이 일반적이라는 것을 의심합니다. 그리고 '오류를 추가하는 것으로 보일 수있다'는 것은 분명하지 않기 때문에 인용이 필요하다.
— Mark
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.