Design By Contract가 효과가 있습니까?[닫은]

https://stackoverflow.com/questions/26455

design-by-contract

09-06-2019
|

문제

Design by Contract를 전문적으로 사용하십니까?프로젝트 시작부터해야 할 일입니까, 아니면 기어를 변경하여 소프트웨어 개발 라이프 사이클에 통합 할 수 있습니까?디자인 접근 방식의 장단점은 무엇입니까?

대학원 과정에서 계약에 의한 설계 접근 방식을 발견했습니다.학문적 환경에서는 꽤 유용한 기술인 것 같습니다.그러나 저는 현재 Design by Contract를 전문적으로 사용하지 않으며이를 사용하는 다른 개발자도 모릅니다.SO 군중으로부터 실제 사용에 대해 듣는 것이 좋을 것입니다.

해결책

그것을 충분히 추천 할 수 없습니다.다음과 같이 인라인 문서 계약 사양을 취하는 제품군이있는 경우 특히 좋습니다. 라코 디스

다음과 같이 생성 된 단위 테스트로 변환합니다. 라코 디스

그러면 실제로 실행중인 테스트를 볼 수 있지만 자동 생성됩니다.그런데 생성 된 테스트는 소스 제어에 체크인해서는 안됩니다.

다른 팁

서로 대화해야하는 응용 프로그램 사이에 인터페이스가있을 때 계약에 따라 디자인을 정말로 감상하게됩니다.

계약이 없으면이 상황은 곧 비난 테니스 게임이됩니다.팀은 계속해서 비난을 받고 있으며 엄청난 시간을 낭비하고 있습니다.

계약을하면 책임이 분명합니다.

발신자가 전제 조건을 충족 했습니까?그렇지 않은 경우 고객 팀에서 수정해야합니다.

유효한 요청을받은 수신자가 게시 조건을 충족 했습니까?그렇지 않은 경우 서버 팀에서 수정해야합니다.

양 당사자가 계약을 준수했지만 결과가 만족스럽지 않습니까?계약이 불충분하며 문제를 에스컬레이션해야합니다.

이를 위해 계약을 주장의 형태로 구현할 필요는 없으며 계약이 문서화되고 모든 당사자가 동의하는지 확인하기 만하면됩니다.

STL, 부스트, MFC, ATL 및 많은 오픈 소스 프로젝트를 살펴보면 ASSERTION 문이 너무 많아 프로젝트를 더욱 안전하게 진행할 수 있음을 알 수 있습니다.

계약에 의한 설계!실제 제품에서 실제로 작동합니다.

Frank Krueger 는 다음과 같이 씁니다. <인용구>

Gaius : Null 포인터 예외는 런타임에 의해 자동으로 발생합니다. 함수 프롤로그에서 해당 항목을 테스트하는 것은 이점이 없습니다.

여기에 대해 두 가지 답변이 있습니다.

Null은 예시 일뿐입니다. square (x)의 경우 결과의 제곱근이 (대략) 매개 변수 값인지 테스트하고 싶습니다. 세터의 경우 값이 실제로 변경되었는지 테스트하고 싶습니다. 원자 적 작업의 경우 모든 구성 요소 작업이 성공했는지 또는 모두 실패했는지 확인하고 싶습니다 (실제로 하나의 성공 테스트와 n 번의 실패 테스트). 약한 형식의 언어로 된 팩토리 메서드의 경우 올바른 종류의 개체가 반환되는지 확인하고 싶습니다. 목록은 계속됩니다. 기본적으로 한 줄의 코드로 테스트 할 수있는 모든 것은 프롤로그 주석의 코드 계약에 매우 적합한 후보입니다.
런타임 예외를 생성하기 때문에 테스트하지 말아야한다는 데 동의하지 않습니다. 무엇이든 런타임 예외를 생성 할 수있는 항목을 테스트해야 합니다. 저는 런타임 예외를 좋아합니다. 시스템을 빠르게 실패 하여 디버깅에 도움이되기 때문입니다. 그러나 예제의 null는 가능한 입력에 대한 결과 값이었습니다. null를 반환하지 않는다는 주장이 있지만, 원한다면 테스트해야합니다.

SOA 영역에서 어떤 작업을 할 때 계약으로 설계하지 않는 것은 절대적으로 어리석은 일이며, 나중에 비트와 조각이 교체 될 수있는 모듈 식 작업을 수행하는 경우 항상 유용합니다.boxen이 관련되어 있습니다.

더 표현적인 문자 시스템 대신 군사 급 프로젝트에서 계약에 의한 디자인을 절대적으로 사용합니다.

약한 유형의 언어 나 동적 범위 (PHP, JavaScript)가있는 언어의 경우 기능 계약도 매우 편리합니다.

그 밖의 모든 경우에는 베타 테스터와 단위 테스트에 의존하지 않습니다.

Gaius : Null 포인터 예외가 런타임에 자동으로 발생합니다. 해당 항목을 테스트해도 이점이 없습니다. 기능 프롤로그에서. 문서에 더 관심이 있다면 정적 분석기 등과 함께 사용할 수있는 주석을 사용합니다 (예를 들어 코드가 주석을 깨지 않도록하기 위해).

Design by Contract와 결합 된 더 강력한 유형 시스템이가는 길인 것 같습니다. 예를 보려면 Spec # 을 참조하세요. <인용구>

Spec # 프로그래밍 언어입니다. 투기# 객체 지향의 확장입니다. 언어 C #. 그것은 유형을 확장합니다 널이 아닌 유형을 포함하는 시스템 확인 된 예외. 그것은 제공합니다 사전 형식으로 방법 계약 및 사후 조건 및 객체 불변.

단위 테스트와 계약 별 설계는 모두 제 경험에서 가치있는 테스트 접근 방식입니다.

시스템 자동 테스트 프레임 워크에서 Design by Contract를 사용해 보았습니다. 내 경험은 단위 테스트로는 쉽게 얻을 수없는 유연성과 가능성을 제공합니다.예를 들어 더 긴 시퀀스를 실행하고 응답 시간은 작업이 실행될 때마다 제한 내에 있습니다.

InfoQ의 프레젠테이션을 보면 Design by contract가 구성 요소 통합 단계에서 기존 단위 테스트에 추가 된 가치있는 것으로 보입니다. 예를 들어 먼저 모의 인터페이스를 만든 다음 나중에 구성 요소를 사용할 수 있습니다. 또는 구성 요소의 새 버전이 출시 될 때

계약 테스트를 통해 설계하기위한 모든 설계 요구 사항을 포괄하는 툴킷을 찾지 못했습니다. .Net / Microsoft 플랫폼에서

저는 실제로 Design by Contract를 매일 사용하지 않습니다.하지만 D 언어로 통합되었음을 알고 있습니다.언어의 일부입니다.

예, 그렇습니다!사실 몇 년 전에 저는 Argument Validation을위한 작은 프레임 워크를 디자인했습니다.저는 다른 백엔드 시스템이 모든 종류의 유효성 검사와 검사를 수행하는 SOA 프로젝트를 수행하고있었습니다.그러나 응답 시간을 늘리기 위해 (입력이 유효하지 않은 경우 및 해당 백엔드 시스템로드를 줄이기 위해) 제공된 서비스의 입력 매개 변수를 검증하기 시작했습니다.Not Null뿐만 아니라 String 패턴에도 적용됩니다.또는 세트 내의 값.또한 매개 변수간에 종속성이있는 경우도 있습니다.

이제 우리가 계약 프레임 워크에 의해 작은 디자인을 구현했음을 알게되었습니다. :)

다음은 소규모 Java 인수 유효성 검사 프레임 워크에 관심이있는 사용자를위한 링크입니다..일반 Java 솔루션으로 구현됩니다.

Go 프로그래밍 언어에는 계약에 의한 디자인을 가능하게하는 구조가 없다는 것을 알았습니다. 패닉 / 지연 / 복구는 지연 및 복구 로직이 패닉을 무시하고 IOW가 깨진 계약을 무시하는 것을 가능하게하는 것과 정확히 일치하지 않습니다. 최소한 필요한 것은 어떤 형태의 복구 불가능한 패닉입니다. 또는 기껏해야 계약 구성 (사전 및 사후 조건, 구현 및 클래스 불변)에 의한 설계의 직접적인 언어 지원. 그러나 Go ship의 지배를받는 언어 순수 주의자들의 강한 머리를 감안할 때, 나는이 일에 거의 변화를주지 않습니다.

패닉 함수의 마지막 지연 함수에서 특별한 assert 오류를 확인하고 복구 중에 스택을 덤프하기 위해 runtime.Breakpoint ()를 호출하여 assert-like 동작을 구현할 수 있습니다. 행동이 조건 적이어야한다는 주장처럼 행동해야합니다. 물론이 접근 방식은 assert를 수행 한 후에 새로운 지연 기능이 추가되면 무너집니다. 대규모 프로젝트에서 정확히 잘못된 시간에 발생하여 버그를 놓치게됩니다.

내 요점은 주장이 여러면에서 유용하여 주위에서 춤을 추는 것이 두통이 될 수 있다는 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow