C #에서 정적 메서드로 인터페이스를 구현할 수없는 이유는 무엇입니까?

C #이 이런 식으로 설계된 이유는 무엇입니까?

내가 이해하는 바와 같이, 인터페이스는 행동을 설명하고 특정 행동이 구현되는 인터페이스를 구현하는 클래스에 대한 계약 의무를 설명하는 목적을 제공합니다.

클래스가 공유 메소드에서 해당 동작을 구현하려면 왜 안됩니까?

다음은 내가 염두에 둔 예입니다.

// These items will be displayed in a list on the screen.
public interface IListItem {
  string ScreenName();
  ...
}

public class Animal: IListItem {
    // All animals will be called "Animal".
    public static string ScreenName() {
        return "Animal";
    }
....
}

public class Person: IListItem {

    private string name;

    // All persons will be called by their individual names.
    public string ScreenName() {
        return name;
    }

    ....

 }

왜이 작업을 수행 할 수 없는지 묻는다고 가정합니다.

public interface IFoo {
    void Bar();
}

public class Foo: IFoo {
    public static void Bar() {}
}

이것은 의미 적으로 나에게 이해가되지 않습니다. 객체와 상호 작용하기위한 계약을 지정하려면 인터페이스에 지정된 메소드가 있어야합니다. 정적 메소드를 사용하면 객체와 상호 작용할 수 없습니다. 구현이 정적 일 수있는 위치에있는 경우 해당 메소드가 실제로 인터페이스에 속하는지 스스로에게 문의해야 할 수 있습니다.

public class Animal: IListItem {
    /* Can be tough to come up with a different, yet meaningful name!
     * A different casing convention, like Java has, would help here.
     */
    public const string AnimalScreenName = "Animal";
    public string ScreenName(){ return AnimalScreenName; }
}

더 복잡한 상황에서는 항상 다른 정적 메서드를 선언하고 위임 할 수 있습니다. 예를 생각해 보았을 때 정적 및 인스턴스 컨텍스트에서 사소한 일을 할 이유를 생각할 수 없으므로 FooBar blob을 절약하고 표시 할 수 있습니다. 좋은 생각이 아닙니다.

필자의 기술적 인 이유는 정적 메소드가 vtable에 없으며 호출 사이트가 컴파일 타임에 선택되기 때문입니다. 재정의 또는 가상 정적 멤버를 가질 수없는 것과 같은 이유입니다. 자세한 내용을 보려면 CS 등급 또는 컴파일러 원이 필요합니다.

정치적 이유로 나는 워커 루 대학에서 수학, 컴퓨터 과학 및 응용 수학 학사 학위를 소지 한 에릭 리퍼 ( Eric Lippert)를 인용 할 것이다 (출처 : LinkedIn ) :

정적 메소드의 핵심 디자인 원칙, 그 이름을 부여하는 원칙 ... 컴파일 타임에 어떤 메소드가 호출 될지 항상 정확하게 결정할 수 있습니다. 즉,이 방법은 코드의 정적 분석에 의해서만 해결 될 수 있습니다.

Lippert는 소위 유형 방법을위한 공간을 남겨 둡니다.

즉, (정적과 같은) 유형과 관련된 메서드는 null이 불가능한 "this"인수 (인스턴스 또는 가상과는 달리)를 사용하지 않지만 호출 된 메서드는 T의 생성 된 유형 ( 컴파일 타임에 결정 해야하는 정적과는 달리).

그러나 그 유용성에 대해서는 아직 확신이 없습니다.

여기서 대부분의 대답은 요점을 놓친 것 같습니다. 다형성은 인스턴스 간뿐만 아니라 유형 간에도 사용할 수 있습니다. 이것은 제네릭을 사용할 때 종종 필요합니다.

제네릭 메서드에 형식 매개 변수가 있고 해당 작업을 수행해야한다고 가정합니다. 우리는 생성자를 알지 못하기 때문에 인스턴스화하고 싶지 않습니다.

예를 들면 다음과 같습니다.

Repository GetRepository<T>()
{
  //need to call T.IsQueryable, but can't!!!
  //need to call T.RowCount
  //need to call T.DoSomeStaticMath(int param)
}

...
var r = GetRepository<Customer>()

불행히도, 나는 "못생긴"대안들만 생각 해낼 수 있습니다.

• 리플렉션 사용 추악하고 인터페이스와 다형성의 아이디어를 능가합니다.

• 완전히 별도의 팩토리 클래스 생성

  이것은 코드의 복잡성을 크게 증가시킬 수 있습니다. 예를 들어 도메인 객체를 모델링하려는 경우 각 객체에는 다른 리포지토리 클래스가 필요합니다.

• 원하는 인터페이스 메소드를 인스턴스화 한 다음 호출

  일반 매개 변수로 사용되는 클래스의 소스를 제어하더라도 구현하기가 어려울 수 있습니다. 그 이유는 예를 들어 인스턴스가 잘 알려진 "DB에 연결됨"상태 일 필요가 있기 때문입니다.

예:

public class Customer 
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  void SomeOtherMethod() 
  { 
    //do work...
  }
}

정적 인터페이스 문제를 해결하기 위해 인스턴스화를 사용하려면 다음을 수행해야합니다.

public class Customer: IDoSomeStaticMath
{
  //create new customer
  public Customer(Transaction t) { ... }

  //open existing customer
  public Customer(Transaction t, int id) { ... }

  //dummy instance
  public Customer() { IsDummy = true; }

  int DoSomeStaticMath(int a) { }

  void SomeOtherMethod() 
  { 
    if(!IsDummy) 
    {
      //do work...
    }
  }
}

이것은 분명히 추악하고 불필요한 것은 다른 모든 방법의 코드를 복잡하게 만듭니다. 분명히, 우아한 해결책도 아닙니다!

나는 그것이 오래된 질문이라는 것을 알고 있지만 흥미 롭습니다. 예가 최고가 아닙니다. 사용 사례를 보여 주면 훨씬 더 명확 할 것이라고 생각합니다.

문자열 DoSomething <T> () 여기서 T : ISomeFunction
{
  if (T.someFunction ())
    ...
}

정적 메소드 가 인터페이스를 구현 하도록하는 것만으로는 원하는 것을 달성 할 수 없습니다. 필요한 것은 인터페이스의 일부로 정적 멤버를 갖는 것 입니다. 특히 물건을 만들 수있을 때 많은 유스 케이스를 상상할 수 있습니다. 내가 제공 할 수있는 두 가지 접근법은 도움이 될 수 있습니다.

1. 위의 DoSomething에 전달할 형식이 type 매개 변수 인 정적 제네릭 클래스를 만듭니다. 이 클래스의 각 변형에는 해당 유형과 관련된 항목을 보유하는 하나 이상의 정적 멤버가 있습니다. 이 정보는 각 관심 클래스에 "정보 등록"루틴을 호출하거나 클래스 변형의 정적 생성자가 실행될 때 정보를 얻기 위해 Reflection을 사용하여 제공 할 수 있습니다. 후자의 접근법은 Comparer <T> .Default ()와 같은 것들에 의해 사용된다고 생각합니다.
2. 관심있는 각 클래스 T에 대해 IGetWhateverClassInfo <T>를 구현하고 "새"제한 조건을 충족시키는 클래스 또는 구조체를 정의하십시오. 클래스에는 실제로 필드가 포함되지 않지만 유형 정보가 포함 된 정적 필드를 반환하는 정적 속성이 있습니다. 해당 클래스 또는 구조체의 유형을 해당 일반 루틴으로 전달하면 인스턴스를 작성하고이를 사용하여 다른 클래스에 대한 정보를 얻을 수 있습니다. 이 목적으로 클래스를 사용하는 경우 매번 새 디스크립터 오브젝트 인스턴스를 구성하지 않아도되도록 위에 표시된대로 정적 제네릭 클래스를 정의해야합니다. 구조체를 사용하는 경우 인스턴스화 비용은 없어야하지만 모든 구조체 유형마다 DoSomething 루틴의 다른 확장이 필요합니다.

이러한 접근법 중 어느 것도 실제로 매력적이지 않습니다. 반면에 CLR에 이러한 종류의 기능을 제공하기 위해 메커니즘이 존재한다면 .net은 매개 변수화 된 "새로운"제약 조건을 지정할 수있게 될 것입니다. 특정 서명이있는 정적 메소드가 있는지 알기가 어렵습니다.)

근시안적인 것 같아요.

원래 설계되었을 때 인터페이스는 클래스 인스턴스에서만 사용되도록 설계되었습니다

IMyInterface val = GetObjectImplementingIMyInterface();
val.SomeThingDefinedinInterface();

제네릭에 대한 제약 조건이 인터페이스에 정적 메서드를 추가했을 때 인터페이스가 실제로 사용 되었기 때문에 인터페이스가 도입 된 것입니다.

(댓글에 응답 :) 이제 변경하려면 CLR을 변경해야하므로 기존 어셈블리와 호환되지 않을 수 있습니다.

인터페이스는 객체의 동작을 지정합니다.

정적 메서드는 객체의 동작을 지정하지 않지만 어떤 방식으로 객체에 영향을주는 동작입니다.

인터페이스가 "계약"을 나타내는 한 정적 클래스가 인터페이스를 구현하는 것이 조용해 보입니다.

위의 주장은 모두 계약에 관한 요점을 놓친 것 같습니다.

인터페이스의 목적은 다형성을 허용하고, 정의 된 인터페이스를 구현하기 위해 정의 된 모든 수의 정의 된 클래스의 인스턴스를 전달할 수 있기 때문에 ... 다형성 호출 내에서 코드를 찾을 수 있음 당신이 부르는 방법. 정적 메소드가 인터페이스를 구현하도록 허용하는 것은 의미가 없습니다.

어떻게 부를까요?

public interface MyInterface { void MyMethod(); }
public class MyClass: MyInterface
{
    public static void MyMethod() { //Do Something; }
}

 // inside of some other class ...  
 // How would you call the method on the interface ???
    MyClass.MyMethod();  // this calls the method normally 
                         // not through the interface...

    // This next fails you can't cast a classname to a different type... 
    // Only instances can be Cast to a different type...
    MyInterface myItf = MyClass as MyInterface;  

제네릭이 아닌 컨텍스트에서 사용되는 정적 메소드와 관련하여 인터페이스에 대한 참조가 있으면 호출 할 수 없으므로 인터페이스에서 허용하는 것이 의미가 없다는 데 동의합니다. 그러나 다형성 컨텍스트가 아니라 일반적인 인터페이스를 사용하여 작성된 언어 설계에는 근본적인 허점이 있습니다. 이 경우 인터페이스는 인터페이스가 아니라 제약 조건입니다. C #에는 인터페이스 외부의 제약 조건이 없으므로 실질적인 기능이 없습니다. 지목 사항:

T SumElements<T>(T initVal, T[] values)
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

여기에는 다형성이 없으며 제네릭은 실제 유형의 객체를 사용하고 + = 연산자를 호출하지만 해당 연산자가 있는지 확실하게 알 수 없으므로 실패합니다. 간단한 해결책은 제약 조건에서 지정하는 것입니다. 연산자가 정적이고 정적 메서드가 인터페이스에있을 수없고 문제가있는 경우 제약 조건이 인터페이스로 표시되므로 간단한 솔루션은 불가능합니다.

C #에 필요한 것은 실제 제약 조건 유형이며 모든 인터페이스도 제약 조건이지만 모든 제약 조건이 인터페이스는 아니지만 다음과 같이 할 수 있습니다.

constraint CHasPlusEquals
{
    static CHasPlusEquals operator + (CHasPlusEquals a, CHasPlusEquals b);
}

T SumElements<T>(T initVal, T[] values) where T : CHasPlusEquals
{
    foreach (var v in values)
    {
        initVal += v;
    }
}

모든 숫자 유형에 대해 IArithmetic을 구현하는 것에 대해 이미 많은 이야기가 있었지만 제약 조건이 다형성 구조가 아니기 때문에 효율성에 대한 우려가 있습니다 .CArithmetic 제약 조건을 설정하면 문제가 해결됩니다.

인터페이스는 상속 구조에 있고 정적 메서드는 상속되지 않습니다.

당신이 원하는 것은 정적 메소드가 Type 또는 해당 유형의 인스턴스를 통해 호출되도록 허용합니다. 이것은 적어도 애매 모호함을 초래할 것이며, 이는 바람직한 특성이 아니다.

중요한지 여부, 최상의 방법 및 성능 문제가 어떤 식 으로든 다른지에 대한 끝없는 논쟁이있을 것입니다. C #을 지원하지 않으면 걱정할 필요가 없습니다.

또한 이러한 요구에 부합하는 컴파일러는 인스턴스와 정적 메소드를보다 엄격하게 분리 할 수있는 일부 최적화를 잃을 수 있습니다.

클래스의 정적 메소드와 비 정적 메소드를 서로 다른 인터페이스로 생각할 수 있습니다. 호출되면 정적 메소드는 싱글 톤 정적 클래스 오브젝트로 해석되고 비 정적 메소드는 처리하는 클래스의 인스턴스로 해석됩니다. 따라서 인터페이스에서 정적 및 비 정적 메소드를 사용하는 경우 실제로 하나의 응집성에 액세스하는 데 인터페이스를 사용하려는 경우 두 개의 인터페이스를 효과적으로 선언하게됩니다.

인터페이스 메소드의 정적 구현이 누락되었거나 Mark Brackett이 "소위 유형 메소드"로 도입 한 예를 제공하려면 다음을 수행하십시오.

데이터베이스 스토리지에서 읽을 때 모든 구조의 테이블에서 읽기를 처리하는 일반 DataTable 클래스가 있습니다. 모든 테이블 특정 정보는 테이블 당 하나의 클래스에 저장되며,이 클래스는 DB의 한 행에 대한 데이터도 보유하며 IDataRow 인터페이스를 구현해야합니다. IDataRow에는 데이터베이스에서 읽을 테이블 구조에 대한 설명이 포함되어 있습니다. DataTable은 DB에서 읽기 전에 IDataRow에서 데이터 구조를 요청해야합니다. 현재 이것은 다음과 같습니다

interface IDataRow {
  string GetDataSTructre();  // How to read data from the DB
  void Read(IDBDataRow);     // How to populate this datarow from DB data
}

public class DataTable<T> : List<T> where T : IDataRow {

  public string GetDataStructure()
    // Desired: Static or Type method:
    // return (T.GetDataStructure());
    // Required: Instantiate a new class:
    return (new T().GetDataStructure());
  }

}

GetDataStructure는 각 테이블을 읽을 때마다 한 번만 필요하며 하나 이상의 인스턴스를 인스턴스화하기위한 오버 헤드는 최소화됩니다. 그러나이 경우에는 좋을 것입니다.

참고 : 인터페이스에 대한 확장 메소드를 작성하여 원하는 것과 유사한 동작을 얻을 수 있습니다. 확장 방법은 재정의 할 수없는 공유 정적 동작입니다. 그러나 불행하게도이 정적 방법은 계약의 일부가 아닙니다.

인터페이스는 정의 된 사용 가능한 기능의 추상 집합입니다.

해당 인터페이스의 메소드가 정적으로 작동하는지 여부는 인터페이스 뒤에 숨겨져 야하는 구현 세부 사항입니다. . 불필요하게 메소드를 특정 방식으로 구현해야하므로 인터페이스 메소드를 정적으로 정의하는 것은 잘못된 것입니다.

메소드가 정적으로 정의 된 경우 인터페이스를 구현하는 클래스는 캡슐화되지 않을 것입니다. 캡슐화는 객체 지향 디자인에서 노력하는 것이 좋습니다. 이유는 다루지 않겠습니다. http://en.wikipedia.org/wiki/Object-oriented . 이러한 이유로 인터페이스에서는 정적 메서드를 사용할 수 없습니다.

정적 클래스는 일반적으로 사용할 수 있도록이 작업을 수행 할 수 있어야합니다. 원하는 결과를 얻으려면 싱글 톤을 대신 구현해야했습니다.

"사용자", "팀"등과 같은 각 엔티티 유형에 대해 "작성", "읽기", "업데이트", "삭제"와 같은 CRUD 메소드를 구현 한 많은 정적 비즈니스 계층 클래스가있었습니다. 그런 다음 기본을 작성했습니다. CRUD 메소드를 구현 한 비즈니스 계층 클래스에 대한 추상 특성이있는 제어. 이를 통해 기본 클래스에서 "만들기", "읽기", "업데이트", "삭제"작업을 자동화 할 수있었습니다. 정적 제한으로 인해 싱글 톤을 사용해야했습니다.

대부분의 사람들은 OOP에서 클래스도 객체이기 때문에 어떤 이유로 c #이 "정적 메소드"를 호출하는 메시지를 가지고 있다는 것을 잊는 것 같습니다. 인스턴스 객체와 클래스 객체 사이에 차이가 있다는 사실은 언어의 결함이나 단점 만 보여줍니다. 그래도 C #에 대한 낙관론 ...

여기에 '유형 방법'이 필요한 예가 있습니다. 일부 소스 XML을 기반으로 클래스 집합 중 하나를 만들고 있습니다. 그래서 나는

  static public bool IsHandled(XElement xml)

각 클래스에서 차례로 호출되는 함수입니다.

그렇지 않으면 부적절한 객체를 만드는 데 시간이 낭비되므로 함수는 정적이어야합니다. @Ian Boyde가 지적했듯이 팩토리 클래스에서 수행 할 수 있지만 복잡성을 추가합니다.

클래스 구현자가 강제로 구현하도록 인터페이스에 추가하는 것이 좋습니다. 이는 상당한 오버 헤드를 유발하지는 않습니다. 컴파일 / 링크 시간 검사일 뿐이며 vtable에는 영향을 미치지 않습니다.

그러나 그것은 또한 약간의 개선이 될 것입니다. 메소드가 정적이므로 호출자로서 명시 적으로 호출해야하므로 구현되지 않은 경우 즉시 컴파일 오류가 발생합니다. 인터페이스에서 지정하도록 허용하면 개발주기 초기에이 오류가 발생하지 않았지만 다른 깨진 인터페이스 문제와 비교하면 사소한 것입니다.

따라서 균형을 잡는 것이 가장 좋은 미미한 기능입니다.

정적 요소를 사용하여 클래스의 특수 인스턴스를 작성하여 Microsoft가 C #에서 정적 클래스를 구현한다는 사실은 정적 기능이 달성되는 방식의 이상입니다. 이론적 인 포인트는 아닙니다.

인터페이스는 클래스 인터페이스의 설명자이거나 상호 작용하는 방법이어야하며 정적 상호 작용을 포함해야합니다. Meriam-Webster의 인터페이스에 대한 일반적인 정의 : 서로 다른 사물이 서로 만나고 서로 소통하거나 서로 영향을 미치는 장소 또는 영역. 클래스 또는 정적 클래스의 정적 구성 요소를 완전히 생략하면 이러한 나쁜 소년의 상호 작용 방식에 대한 많은 부분을 무시합니다.

정적 클래스가있는 인터페이스를 사용할 수있는 곳이 매우 유용한 예는 다음과 같습니다.

public interface ICrudModel<T, Tk>
{
    Boolean Create(T obj);
    T Retrieve(Tk key);
    Boolean Update(T obj);
    Boolean Delete(T obj);
}

현재, 나는 아무것도 잊지 않고 있는지 확인하기 위해 어떤 종류의 검사없이 이러한 메소드를 포함하는 정적 클래스를 작성합니다. OOP 이전의 나쁜 프로그래밍 시대와 같습니다.

C #과 CLR은 Java와 마찬가지로 인터페이스에서 정적 메서드를 지원해야합니다. 정적 수정자는 계약 정의의 일부이며, 특히 거동 및 반환 값이 호출마다 다를 수 있지만 인스턴스에 따라 다르지 않음을 의미합니다.

즉, 인터페이스에서 정적 메서드를 사용하려고 할 때 사용할 수 없으면 주석을 대신 사용하는 것이 좋습니다. 원하는 기능을 얻을 수 있습니다.

나는 짧은 대답은 "제로 유용성이 없기 때문에"라고 생각합니다. 인터페이스 메소드를 호출하려면 유형의 인스턴스가 필요합니다. 인스턴스 메소드에서 원하는 정적 메소드를 호출 할 수 있습니다.

나는 C #이 이런 종류의 상황을 위해 다른 키워드가 필요하다는 사실에 의문을 제기하고 있다고 생각합니다. 리턴 값이 호출 된 유형에만 의존하는 메소드를 원합니다. 해당 유형을 알 수 없으면 "정적"이라고 부를 수 없습니다. 그러나 유형이 알려지면 정적이됩니다. "정적되지 않은 정적"은 아직 정적 인 것이 아니라 일단 수신 유형을 알면 그대로입니다. 이것은 완벽하게 좋은 개념이므로 프로그래머가 계속 요구합니다. 그러나 디자이너들이 언어에 대해 생각하는 방식에는 맞지 않았습니다.

사용할 수 없으므로 아래 표시된 방식으로 비 정적 방법을 사용했습니다. 정확히 이상적이지는 않지만 적어도 나에게는 적합하지 않은 접근법을 볼 수 없습니다.

public interface IZeroWrapper<TNumber> {
  TNumber Zero {get;}
}

public class DoubleWrapper: IZeroWrapper<double> {
  public double Zero { get { return 0; } }
}

객체 지향 개념에 따라 클래스에 의해 구현되고 객체를 사용하여 이러한 구현 된 함수에 액세스하는 계약이 있습니다.

따라서 인터페이스 계약 메소드에 액세스하려면 오브젝트를 작성해야합니다. 정적 메소드의 경우 항상 허용되지 않아야합니다. 정적 클래스, 메소드 및 변수는 해당 영역 (또는 클래스)의 객체를 만들지 않고 객체를 요구하지 않고 메모리에로드하거나 객체 생성이 필요하지 않다고 말할 수 있습니다.

개념적 으로 인터페이스가 정적 메소드를 포함하는 계약을 정의 할 수없는 이유는 없습니다.

현재 C # 언어 구현의 경우 제한은 기본 클래스 및 인터페이스의 상속이 허용되기 때문입니다. "클래스 SomeBaseClass"가 "인터페이스 ISomeInterface"를 구현하고 "클래스 SomeDerivedClass : SomeBaseClass, ISomeInterface"도 인터페이스를 구현하는 경우, 정적 메소드는 인스턴스 메소드와 동일한 서명을 가질 수 없으므로 인터페이스 메소드를 구현하는 정적 메소드 컴파일에 실패합니다. 인터페이스를 구현하려면 기본 클래스에 있어야합니다.

정적 클래스는 기능적으로 싱글 톤과 동일하며 구문이 깔끔한 싱글 톤과 동일한 목적으로 사용됩니다. 싱글 톤이 인터페이스를 구현할 수 있으므로 정적에 의한 인터페이스 구현은 개념적으로 유효합니다.

따라서 단순히 상속에서 동일한 이름의 정적 메소드와 정적 메소드에 대한 C # 이름 충돌의 한계로 간단히 요약됩니다. 정적 메소드 계약 (인터페이스)을 지원하기 위해 C #을 "업그레이드"할 수없는 이유는 없습니다.

클래스가 인터페이스를 구현하면 인터페이스 멤버를위한 인스턴스가 생성됩니다. 정적 유형에는 인스턴스가 없지만 인터페이스에 정적 서명이있을 필요는 없습니다.