구현하기 전에 인터페이스 API를 작성해야합니까?

최근에보다 "조직화 된"프로그래밍에 대해 연구하고 있으며 구현이 아닌 인터페이스로 프로그래밍해야한다는 것을 배웠습니다. 이를 염두에두고, 가능한 경우 구현을 작성하기 전에 인터페이스에서 프로젝트를 "스케치"하는 것이 더 좋을까요?

이 경우 타사 라이브러리 (예 : Lidgren)를 사용하는 경우 인터페이스로 랩핑하고 IOC 컨테이너를 통해 해결해야합니까? 아니면 인터페이스에 노출해도됩니까?

불행히도, 이것은 종종 개인 취향으로 요약됩니다.

그러나 지금까지 설명한 내용이 좋습니다. 실제로 원하는 경우 다음 방법을 사용할 수 있습니다.

1. 애플리케이션 스켈레톤을 인터페이스, 추상 클래스 (스텁) 및 클래스 (또한 스텁)로 작성하십시오.
2. 해당 인터페이스 및 스텁에 대해 테스트를 작성하십시오 (현재는 실패합니다).
3. 구현을 작성하십시오 (구현이 끝나면 테스트가 통과하기 시작합니다)

보다 "조직화 된"코드를 작성하는 데 집중하고 있습니다. TDD를 따르는 것이 도움이 될 것입니다.

몇 가지 추가 사항 :

• IoC 컨테이너가 편리합니다. 그들과 DI를 최대한 많이 사용하십시오.
• 마 제 3의 라이브러리를 래핑. 이렇게하면 코드 (제어하는 코드)와 타사 코드 (제어하지 않는 코드) 사이의 연결이 느슨해집니다.

그렇습니다. 알려진 구현이 아닌 인터페이스에 대해 코딩해야하며, 자신의 코드에서 인터페이스를 생성하지 않고 먼저 인터페이스를 구성해야합니다.

두 가지 권장 사항의 이유는 대체로 동일합니다. 컴퓨터 프로그래밍은 주로 인적 요소에 관한 것입니다. 많은 사람들이이 놀라운 사실을 알고 있지만 다음과 같은 점을 고려하십시오. 동일하게 작동하는 동일한 컴퓨팅 문제를 해결하는 방법은 거의 무한합니다. 거의 모든 사람들은 글을 쓰지 않은 사람 (또는 사실 저자에게 잠시 후)을 이해하는 것이 완전히 불가능합니다.

좋은 소프트웨어 엔지니어링은 소스 코드를 나중에 작업 할 수있는 방식으로 원하는 효과 (적절한 효율로 올바른 계산)를 얻는 방법에 관한 것입니다. 인터페이스와 API는 해당 분야의 중요한 부분입니다. 한 번에 한 수준의 설명으로 문제에 대해 생각할 수 있습니다. 이는 비즈니스 일관성 규칙 과 링크 된 목록 구현에 대해 생각하는 것보다 훨씬 쉬우 므로 클라이언트 프로그래머가 원하는 방식으로 코드를 사용하도록 허용하는 것보다 이러한 분리를 강제로 적용하는 것이 좋습니다 .

이것은 그들이 쓰는 모든 것을 이해하고 평범한 사상가보다 훨씬 뛰어나고 "더 적은"프로그래머에게 문제를 야기하는 모든 복잡성을 처리 할 수 ​​있다고 확신하는 많은 카우보이 프로그래머에게는 믿기 어렵습니다. 자신의인지 한계를 인식하지 못하는 것은 매우 흔한 현상입니다. 이것이 코드 구성의 모범 사례가 매우 중요하고 종종 무시되는 이유입니다.

반복하면 인터페이스와 API 장벽은 자신과 만 협력하는 경우에도 크게 좋습니다 . 외부 라이브러리의 경우 잘 생각한 API를 가져와도 라이브러리를 다른 라이브러리로 교체하지 않아도되는 한 API 사용에 아무런 문제가 없습니다. 그렇지 않으면 래퍼 또는 부패 방지 계층이 매우 좋습니다.

인터페이스로 프로그래밍하는 것만으로도 TDD (Test Driven Development / Design)를 보지 않겠습니까?

많은 사람들이 TDD를 테스트 관행이라고 생각하지만 실제로 테스트를 통해 코드를 사용하는 방법 (초기 단위 테스트를 통하지 만 통합 테스트를 통할 수도 있음)을 테스트에 노출시키는 디자인 방식입니다.

인터페이스 프로그래밍은 툴셋에서 중요한 무기이지만 대부분의 경우처럼 항상 적절한 솔루션 / 기술 / 연습은 아닙니다. 필요한 인터페이스에 프로그래밍해야합니다.

TDD를 사용하면 그러한 인터페이스가 중요한 곳과 솔직히 중요하지 않은 곳을 탐색하게됩니다. 그리고 마지막에는 코드베이스에 걸쳐 꽤 좋은 단위 테스트 세트가 있어야합니다.

써드 파티 라이브러리를 사용하는 경우에는 적절한 경우 자신의 추상화로 랩핑하는 것이 좋습니다. 귀하의 API 클라이언트가 그들에 대해 "알도록"하지 마십시오

행운을 빕니다!

[편집 : megaflight의 답변을 보았습니다-완전히 동의합니다]

과잉이라고 생각합니다. API 사용자가 특정 방식으로 무언가를 구현 / 사용하도록 강요 할 필요가 없다면 나는 그것을 버릴 것입니다. 인터페이스는 계약입니다. 필요하지 않으면 왜 나에게 하나를 주시겠습니까?

사람들이 인터페이스를 과도하게 사용한다고 생각합니다. 대부분의 경우 필요하지 않은 복잡한 계층을 추가하고 있습니다.

계약에 대한 프로그래밍은 거의 항상 좋은 생각입니다. 그 계약은 인터페이스 일 필요는 없으며 대신 클래스에 의해 이행 될 수 있습니다. 내 의견으로는, 단위 테스트 문제와 모의 프레임 워크로 인해 인터페이스가 DI와 함께 다소 과용되었습니다.

개인적으로 계약을 한 번 이상 구현할 수 있거나 가질 가능성이있을 때만 인터페이스를 가져 오는 것을 선호합니다. 인터페이스는 데이터 액세스를 추상화하려는 리포지토리에는 유용하지만 상대적으로 융통성이없는 표준 비즈니스 로직에는 적합하지 않습니다.

인터페이스가 없으면 특히 순수 주의자에게 단위 테스트에 문제가 발생할 수 있습니다. 그러나 나는 내부 의존성이 아닌 내 프로그램의 외부 의존성을 조롱하는 데 관심이 있습니다. 테스트에서 코드 구조를 에코하지 않고 코드 유효성 검사를 수행하기를 원합니다.