인터페이스 기반 프로그래밍, 제대로하고 있습니까?

OK 그래서 내 코드 기반에서 인터페이스를 사용하기로 결정했는데 이것은 특정 작업에 대해 꽤 잘 작동합니다. 예를 들어 IUrlBuilder를 구현하는 URL 작성기 클래스가 있으며 구현이 중요하지 않습니다. 똑똑하지만 예를 들어이 인터페이스를 사용하십시오.인터페이스 기반 프로그래밍, 제대로하고 있습니까?

namespace SproutMessagingFramework.Webtext.Interfaces 
{ 
using System.Net; 

public interface ICookieJar 
{ 
    CookieCollection Collection { get; set; } 
    CookieContainer Container { get; set; } 

    void AddResponse(HttpWebResponse Response); 
    void AddResponse(HttpWebResponse Response, string Path, string Domain); 
} 
}

이 인터페이스는 매우 구체적입니다.이 두 가지 방법은 구체적인 클래스가 이미 수행하고있는 것보다 많이 수행하지 않을 것입니다. 그렇다면 왜 내가 인터페이스로 만들었습니까? 그럼 내 생각은 AddResponse의 구현을 변경해야하는 경우입니다.

이게 맞습니까? 아니면 코드베이스가 부풀어 오르고 있습니까?

출처

2010-11-29 deanvmc

인터페이스 기반 프로그래밍은 디커플링에 관한 것입니다. 버전을 변경하거나 다른 구현을하려고합니까? –

나는 의도에 대해 많이 걱정하지 않습니다. 만큼 내 코드 기반을 확장하는 수단은 내게 맞는 코드에 존재합니다. 나는 어떤 식 으로든 프레임 워크를 만들지는 않겠지 만 동시에 발에서 자신을 쏘지 않을 것이다. – deanvmc

인터페이스는 특정 클래스와 1 : 1로 대응할 수 있습니다. 이것은 (다른 것들 중에서) mock 프레임 워크와의 통합을 허용합니다. 테스트 환경에서 쿠키 괴물의 동작을 검증하면서 실제 쿠키를 대신하는 쿠키 병을 대체합니다.

그러나 인터페이스가 클래스 기능의 하위 집합을 정의하는 것이 더 일반적이며 종종 클래스 자체에 의도적으로 직각이 될 수 있습니다. 직교 인터페이스의 좋은 예가 IDisposable입니다. 리소스 정리는 클래스가 실제로 설계된 것이 아니지만 클래스는 소켓, 파일 설명자 등과 같은 관리되지 않는 리소스의 클린 교정을 지원할 때 IDisposable을 구현합니다.

다른 일반적인 사용법은 ICollection 및 IEnumerable 같은 통합 컨테이너 모델을 제공하는 것입니다.

마지막으로 클래스는 일반적으로 기능의 직교 단면에 해당하는 여러 인터페이스를 구현합니다.

출처

2010-11-29 12:46:21

고마워, 나는 단지 내 구현을 확인하고 있었다고 생각한다. 나는 항상 내 코드베이스에 "보풀"을 추가하는 것에 대해 걱정한다. 그러나 구현 이후 인터페이스를 사용하여 개념화를 가속화 할 수 있었기 때문에 진실을 알 수 있습니다. – deanvmc

AddResponse 메서드를 구현하는 방법이 하나 밖에없는 경우에도 인터페이스의 특정 인스턴스로 호출을 전달하기 전에 무언가를 수행하는 ICookieJar 구현을 상상할 수 있습니다.

예를 들어, 진단 로깅을 추가하는 구현 또는 저장된 쿠키의 이름을 투명하게 변경하는 구현입니다.

출처

2010-11-29 12:49:14

건배, 좋은 지적입니다. – deanvmc

인터페이스 기반 프로그래밍, 제대로하고 있습니까?

답변

관련 문제