확장 인터페이스 패턴

StackOverflow https://stackoverflow.com/questions/8042

  •  08-06-2019
  •  | 
  •  

문제

.Net 3.5의 새로운 확장 기능을 사용하면 인터페이스에서 기능을 분리할 수 있습니다.

예를 들어 .Net 2.0에서

public interface IHaveChildren {
    string ParentType { get; }
    int ParentId { get; }

    List<IChild> GetChildren()
}

(3.5에서) 다음과 같이 될 수 있습니다:

public interface IHaveChildren {
    string ParentType { get; }
    int ParentId { get; }
}

public static class HaveChildrenExtension {
    public static List<IChild> GetChildren( this IHaveChildren ) {
        //logic to get children by parent type and id
        //shared for all classes implementing IHaveChildren 
    }
}

이것은 많은 인터페이스에 대해 더 나은 메커니즘인 것 같습니다.이 코드를 공유하기 위해 더 이상 추상 기반이 필요하지 않으며 기능적으로 코드는 동일하게 작동합니다.이렇게 하면 코드를 더 유지 관리하기 쉽고 테스트하기 쉽게 만들 수 있습니다.

유일한 단점은 추상 기반 구현이 가상일 수 있지만 이를 해결할 수 있다는 것입니다(인스턴스 메소드가 동일한 이름을 가진 확장 메소드를 숨길 수 있습니까?)그렇게 하면 코드가 혼란스러울까요?)

이 패턴을 정기적으로 사용하지 않는 다른 이유가 있나요?

설명:

네, 확장 방법의 경향은 어디에서나 사용되는 것으로 보입니다.나는 많은 동료 검토 없이 .Net 값 유형에 대해 특히 주의할 것입니다. (제 생각에는 문자열에 있는 유일한 값은 다음과 같습니다. .SplitToDictionary() - 비슷하다 .Split() 하지만 키-값 구분 기호도 사용함)

나는 거기에 전체적인 모범 사례 토론이 있다고 생각합니다 ;-)

(덧붙여서:DannySmurf, PM이 무서운 것 같네요.)

여기서는 이전에 인터페이스 메서드가 있었던 확장 메서드를 사용하는 방법에 대해 구체적으로 묻고 있습니다.

나는 많은 수준의 추상 기본 클래스를 피하려고 노력하고 있습니다. 이러한 모델을 구현하는 클래스에는 대부분 이미 기본 클래스가 있습니다.내 생각에 이 모델은 객체 계층을 추가하는 것보다 유지 관리가 더 용이하고 덜 과도하게 결합될 수 있다고 생각합니다.

이것이 MS가 Linq용 IEnumerable 및 IQueryable에 수행한 작업입니까?

도움이 되었습니까?

해결책

나는 확장 메서드를 현명하게 사용하면 인터페이스를 (추상) 기본 클래스와 더 동등한 위치에 놓을 수 있다고 생각합니다.


버전 관리. 인터페이스에 비해 기본 클래스가 갖는 한 가지 장점은 이후 버전에서 새 가상 멤버를 쉽게 추가할 수 있다는 점입니다. 반면 인터페이스에 멤버를 추가하면 이전 버전의 라이브러리에 대해 빌드된 구현이 중단됩니다.대신, 새 멤버가 포함된 새 버전의 인터페이스를 만들어야 하며, 라이브러리는 원래 인터페이스를 구현하는 레거시 개체에 대한 액세스를 제한하거나 해결해야 합니다.

구체적인 예로, 라이브러리의 첫 번째 버전은 다음과 같이 인터페이스를 정의할 수 있습니다.

public interface INode {
  INode Root { get; }
  List<INode> GetChildren( );
}

라이브러리가 출시되면 현재 사용자를 중단하지 않고는 인터페이스를 수정할 수 없습니다.대신, 다음 릴리스에서는 추가 기능을 추가하기 위해 새 인터페이스를 정의해야 합니다.

public interface IChildNode : INode {
  INode Parent { get; }
}

그러나 새 라이브러리의 사용자만 새 인터페이스를 구현할 수 있습니다.레거시 코드로 작업하려면 확장 메서드가 훌륭하게 처리할 수 있는 이전 구현을 조정해야 합니다.

public static class NodeExtensions {
  public INode GetParent( this INode node ) {
    // If the node implements the new interface, call it directly.
    var childNode = node as IChildNode;
    if( !object.ReferenceEquals( childNode, null ) )
      return childNode.Parent;

    // Otherwise, fall back on a default implementation.
    return FindParent( node, node.Root );
  }
}

이제 새 라이브러리의 모든 사용자는 레거시 구현과 최신 구현을 동일하게 처리할 수 있습니다.


과부하. 확장 메서드가 유용할 수 있는 또 다른 영역은 인터페이스 메서드에 대한 오버로드를 제공하는 것입니다.동작을 제어하기 위해 여러 매개변수가 있는 메소드가 있을 수 있으며, 90%의 경우 처음 한두 개만 중요합니다.C#에서는 매개 변수에 대한 기본값 설정을 허용하지 않으므로 사용자는 매번 완전히 매개 변수화된 메서드를 호출해야 하거나 모든 구현에서 핵심 메서드에 대한 사소한 오버로드를 구현해야 합니다.

대신 확장 메서드를 사용하여 간단한 오버로드 구현을 제공할 수 있습니다.

public interface ILongMethod {
  public bool LongMethod( string s, double d, int i, object o, ... );
}

...
public static LongMethodExtensions {
  public bool LongMethod( this ILongMethod lm, string s, double d ) {
    lm.LongMethod( s, d, 0, null );
  }
  ...
}


이 두 경우 모두 인터페이스에서 제공하는 작업 측면에서 작성되었으며 사소하거나 잘 알려진 기본 구현을 포함합니다.즉, 클래스에서 한 번만 상속할 수 있으며 확장 메서드를 대상으로 사용하면 인터페이스에 부족한 기본 클래스에서 제공하는 일부 세부 사항을 처리하는 귀중한 방법을 제공할 수 있습니다. :)

편집하다: Joe Duffy의 관련 게시물: 기본 인터페이스 메소드 구현으로서의 확장 메소드

다른 팁

확장 메서드는 다음과 같이 사용해야 합니다.확장.중요한 구조/디자인 관련 코드나 중요하지 않은 작업은 클래스나 인터페이스로 구성/상속되는 객체에 넣어야 합니다.

다른 객체가 확장된 객체를 사용하려고 시도하면 확장이 표시되지 않으며 다시 구현/재참조해야 할 수도 있습니다.

전통적인 통념은 확장 메서드는 다음 용도로만 사용해야 한다는 것입니다.

  • Vaibhav가 언급한 유틸리티 클래스
  • 봉인된 타사 API 확장

내 생각에 확장 메서드가 대체하는 가장 좋은 것은 모든 프로젝트에서 찾을 수 있는 모든 유틸리티 클래스입니다.

적어도 지금으로서는 다른 확장 방법을 사용하면 직장에서 혼란을 초래할 수 있다고 생각합니다.

내 두 비트.

확장 메서드를 사용하여 도메인/모델과 UI/뷰 기능을 분리하는 것은 좋은 일이라고 봅니다. 특히 두 기능이 별도의 네임스페이스에 상주할 수 있기 때문입니다.

예를 들어:

namespace Model
{
    class Person
    {
        public string Title { get; set; }
        public string FirstName { get; set; }
        public string Surname { get; set; }
    }
}

namespace View
{
    static class PersonExtensions
    {
        public static string FullName(this Model.Person p)
        {
            return p.Title + " " + p.FirstName + " " + p.Surname;
        }

        public static string FormalName(this Model.Person p)
        {
            return p.Title + " " + p.FirstName[0] + ". " + p.Surname;
        }
    }
}

이런 방식으로 확장 메서드를 XAML 데이터 템플릿과 유사하게 사용할 수 있습니다.클래스의 비공개/보호 멤버에 액세스할 수는 없지만 이를 통해 애플리케이션 전체에서 과도한 코드 중복 없이 데이터 추상화가 유지될 수 있습니다.

인터페이스 확장에는 아무런 문제가 없습니다. 실제로 LINQ가 컬렉션 클래스에 확장 메서드를 추가하는 방식은 이와 같습니다.

즉, 해당 인터페이스를 구현하는 모든 클래스에서 동일한 기능을 제공해야 하고 해당 기능이 파생 클래스의 "공식" 구현의 일부가 아닌 경우에만 이 작업을 수행해야 합니다. 클래스.새로운 기능이 필요한 모든 파생 유형에 대해 확장 메서드를 작성하는 것이 비실용적이라면 인터페이스를 확장하는 것도 좋습니다.

공통 기능을 공유하기 위해 기본 클래스 사용을 옹호하는 사람들이 많이 있습니다.이에 주의하세요. 상속보다 구성을 선호해야 합니다.상속은 모델링 관점에서 타당할 때 다형성에만 사용해야 합니다.코드 재사용을 위한 좋은 도구는 아닙니다.

질문은 다음과 같습니다.이 작업을 수행할 때 제한 사항에 유의하세요. 예를 들어 표시된 코드에서 확장 메서드를 사용하여 GetChildren을 구현하면 이 구현이 효과적으로 '봉인'되고 필요한 경우 IHaveChildren impl이 자체 제공을 허용하지 않습니다.이것이 괜찮다면 확장 방법 접근 방식은 그다지 신경 쓰지 않습니다.이는 확정된 것이 아니며 일반적으로 나중에 더 많은 유연성이 필요할 때 쉽게 리팩토링할 수 있습니다.

유연성을 높이려면 전략 패턴을 사용하는 것이 더 나을 수 있습니다.다음과 같은 것 :

public interface IHaveChildren 
{
    string ParentType { get; }
    int ParentId { get; }
}

public interface IChildIterator
{
    IEnumerable<IChild> GetChildren();
}

public void DefaultChildIterator : IChildIterator
{
    private readonly IHaveChildren _parent;

    public DefaultChildIterator(IHaveChildren parent)
    {
        _parent = parent; 
    }

    public IEnumerable<IChild> GetChildren() 
    { 
        // default child iterator impl
    }
}

public class Node : IHaveChildren, IChildIterator
{ 
    // *snip*

    public IEnumerable<IChild> GetChildren()
    {
        return new DefaultChildIterator(this).GetChildren();
    }
}

조금 더.

여러 인터페이스에 동일한 확장 메서드 서명이 있는 경우 호출자를 하나의 인터페이스 유형으로 명시적으로 변환한 다음 메서드를 호출해야 합니다.예:

((IFirst)this).AmbigousMethod()

아야.인터페이스를 확장하지 마십시오.
인터페이스는 클래스가 구현해야 하는 깨끗한 계약이며 해당 클래스의 사용법입니다. ~ 해야 하다 이것이 올바르게 작동하려면 핵심 인터페이스에 있는 것으로 제한되어야 합니다.

그렇기 때문에 항상 인터페이스를 실제 클래스 대신 유형으로 선언합니다.

IInterface variable = new ImplementingClass();

오른쪽?

일부 기능이 추가된 계약이 정말로 필요하다면 추상 클래스를 사용하는 것이 좋습니다.

Rob Connery(Subsonic 및 MVC Storefront)는 자신의 Storefront 애플리케이션에서 IRepository와 유사한 패턴을 구현했습니다.위의 패턴은 아니지만 몇 가지 유사점을 공유합니다.

데이터 계층은 소비 계층이 그 위에 필터링 및 정렬 표현식을 적용할 수 있도록 허용하는 IQueryable을 반환합니다.예를 들어, 보너스는 단일 GetProducts 메서드를 지정한 다음 소비 계층에서 정렬, 필터링 또는 특정 범위의 결과를 원하는 방식을 적절하게 결정할 수 있다는 것입니다.

전통적인 접근 방식은 아니지만 매우 멋지고 확실히 DRY 사례입니다.

내가 볼 수 있는 한 가지 문제는 대기업에서 이 패턴으로 인해 누구나 코드를 이해하고 사용하기 어려워질 수 있다는 것입니다(불가능하지는 않더라도).여러 개발자가 해당 클래스와 별도로 기존 클래스에 자신의 메서드를 지속적으로 추가하는 경우(그리고 BCL 클래스에도 신이 우리 모두를 도우신다면) 코드 기반이 통제 불능 상태로 빠르게 회전하는 것을 볼 수 있습니다.

내 직장에서도 이런 일이 일어나는 것을 볼 수 있었습니다. 우리가 작업하는 모든 코드를 UI나 데이터 액세스 레이어에 추가하려는 PM의 바람과 함께 PM이 20~30가지 메서드를 추가해야 한다고 고집하는 모습을 볼 수 있었습니다. 문자열 처리와 접선적으로만 관련된 System.String입니다.

비슷한 문제를 해결해야 했습니다.IIDable은 긴 getId() 함수가 있는 인터페이스인 확장 함수에 List<IIDable>을 전달하고 싶었습니다.GetIds(this List<IIDable> bla)를 사용해 보았으나 컴파일러에서 이를 허용하지 않았습니다.대신 템플릿을 사용한 다음 함수 내부에서 인터페이스 유형으로 유형을 캐스팅했습니다.일부 linq에서 SQL 생성 클래스에 대해 이 함수가 필요했습니다.

이게 도움이 되길 바란다 :)

    public static List<long> GetIds<T>(this List<T> original){
        List<long> ret = new List<long>();
        if (original == null)
            return ret;

        try
        {
            foreach (T t in original)
            {
                IIDable idable = (IIDable)t;
                ret.Add(idable.getId());
            }
            return ret;
        }
        catch (Exception)
        {
            throw new Exception("Class calling this extension must implement IIDable interface");
        }
라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top