는 인터페이스 내가 플러그인과 함께 응용 프로그램을 확장하는 메커니즘을 제공하는 닷넷 응용 프로그램을 C#을 -constructor

Question

의 서명을 정의 할 수 있습니다. 각 플러그인은 플러그인 인터페이스를 구현해야하며 하나의 매개 변수 (자원 컨텍스트)를 수신하는 생성자를 더 제공해야합니다. 나는 반사를 통해 볼 플러그인 클래스의 인스턴스 동안

, 필요한 생성자가 존재하는 경우 예, 나는 (반사를 통해) 클래스를 인스턴스화합니다. 생성자가 없으면 원하는 생성자를 사용할 수 없기 때문에 플러그인을 만들 수 없다는 예외를 throw합니다.

제 질문은 플러그인 인터페이스에서 생성자의 서명을 선언 할 수있는 방법이 있다면 플러그인 인터페이스를 구현하는 모든 사람도 생성자에게 원하는 서명을 제공해야한다는 것입니다. 이렇게하면 플러그인을 쉽게 만들 수 있습니다.

나는 그런 가능성이 나는 그런 기능이 인터페이스를 위해 설계되었지만, 아마도 누군가가이 작업을 수행 성명을 알고 무엇을 주요 목적으로하지 떨어진다 생각하기 때문에 존재한다고 생각하지 않는다, 뭔가 같은 :

public interface IPlugin { 
    ctor(IResourceContext resourceContext); 
    int AnotherPluginFunction(); 
} 

나는 매개 변수없이 생성자를 변경하고 속성을 통해 자원 컨텍스트를 설정하는 것을 원하지 않는다고 추가하고 싶습니다. 이렇게하면 플러그인 작성이 훨씬 더 복잡해지기 때문입니다. 플러그인을 작성하는 사람은 프로그래밍에 익숙한 사람이 아닙니다. 플러그인은 앱에서 시각화 할 통계 데이터를 계산하는 데 사용됩니다. 모든 답변을

---

감사합니다.

필자는 플러그인 프로그래머가 추상 클래스를 상속 받아 자신의 기본 클래스에서 상속받을 가능성이 없어지기를 원치 않기 때문에 인터페이스로 둡니다. . 게다가 추상 클래스로부터 파생되었다고해서 플러그인 프로그래머가 필요한 생성자를 실제로 제공하지는 않습니다. 프로그래머는 원하는 매개 변수를 포함하는 하나의 생성자 만 추가 할 수 있지만 추가 매개 변수가있는 경우에도 문제가 발생합니다 (Ken Browning의 답변에 대한 주석 참조). 나는 이러한 속성을 원하지 않는 내 게시물에서 언급했지만

, 나는 나는 그것이 가장 적합한 솔루션입니다 내 상황에서 생각하기 때문에 가능으로 대니 Varod의 답을 표시했다. 대답 한 모든 사람들에게 감사드립니다.

Answer 1

확장 성 플러그인은 내가하는 일은

확인 플러그인을 다음 중 하나입니다 인터페이스를 구현하거나 적절한 "플러그인 소켓"의 기본 클래스를 상속 ... 내 마음에 드는 것입니다.

일부 경우 플러그인이 일종의 X 인 경우 기본 클래스가 더 적합하며 일부 인터페이스에서는
이 더 적합합니다 (플러그인이 IX 인 경우).

내가 대신 내가 그의 속성과 매개 변수가없는 public 생성자를 사용하여 구조에 컨텍스트를 전달하지 않습니다.

이렇게하면 리플렉션을 사용하여 플러그 - 인을 쉽게 deserialize 할 수 있습니다. 다른 사람들이 배관 세부 사항을 돌봐 추상 클래스를 사용하여 언급했듯이

는

Answer 2

아니요, 존재하지 않습니다. 당신은 아마도 추상적 인 수업을 찾고있을 것입니다.

Answer 3

인터페이스가 생성자를 선언 할 수 없습니다. 대신에 추상 클래스를 사용해보십시오.

Answer 4

불행하게도, C#에서 인터페이스는 메서드, 속성, 이벤트 또는 인덱서를 포함 할 수 있습니다.

당신이 사용하고있는 모든 플러그인을 상속 할 추상 클래스 수 있습니다. 이 경우 생성자 서명을 구현하도록 강제 할 수 있습니다.

Answer 5

인터페이스는/선언 생성자를 적용 할 수 없습니다.

및 생성자의 가장 가능성이 구현 제공하는 추상 기본 클래스 생성 인터페이스 정의 -. 아마 전달 된 자원 컨텍스트를 절약

가 저자 플러그인, 격려,하지만 필요하지 않습니다 기본 클래스에서 파생됩니다.기본 클래스가 제공 할 수있는 다른 유용한 메소드가있을 수 있습니다.

는 플러그인을 확인하는 반사를 계속 사용합니다.

Answer 6

당신이 달성하려고하는지에 대한 일반적인 패턴이다. 여기에 소비자가 추상 기본 클래스 플러그인에서 상속하는 경우 특별한 매개 변수로 생성자의 필요성을 방지 한 디자인 :

public interface IPlugin 
{ 
    void Initialize(IResourceContext context);  

    //Other methods... 
} 

public abstract class Plugin : IPlugin 
{ 
    protected IResourceContext Context { get; private set; } 

    void IPlugin.Initialize(IResourceContext context) 
    { 
     Context = context; 
    } 

    //Abstract declaration of other methods... 
} 

귀하의 코드는 플러그인을 만든 후 무대 뒤에서 초기화를 호출 할 수있다,하지만이 세부 사항입니다 일반적으로 IPlugin을 직접 구현할 필요가 없으므로 일반 사용자로부터 숨겨집니다. 일반 사용자는 Plugin 하위 항목을 정의하고 Context 속성으로 작업 할 수 있습니다.

또한 그들은 당신이 무슨 일을하는지에 대한 아마 잔인한 사람이야 있지만, (예 Ninject) 다양한 의존성 주입 프레임 워크를 조사 할 수 있습니다. 그럼에도 불구하고 어떻게 작동하는지 살펴보면 종속성 주입을 관리 할 수있는 여러 가지 방법에 대한 아이디어를 얻을 수 있습니다.

Answer 7

또는, 팩토리를 사용하려고 할 수 있습니다 생성자 서명을하는 방법의 또 다른 유형의 서명합니다 같은

public abstract class PluginFactory 
{ 
    public abstract IPlugin Create(IResourceContext context); 
} 

하고 뭔가를 (그리고 나는 그것을 짧게하는 것이 엉망이 부분하려는 경우 , 따라서 편집) :

public class PluginContainer 
{ 
    public IPlugin LoadPlugin<T>(IResourceContext context) where T: PluginFactory, new() 
    { 
     var factory = new T(); 
     return factory.Create(context); 
    } 
}