Был бы “Ограниченные Типы” быть полезным в VB/C#?

Я думаю, пока поверхностно полезный, этот вид вещи лучше обрабатывается одним из двух:

• Утиный Ввод через динамический (прибывающий в VS2010) для значительно большей гибкости, хотя удаляя безопасность типов.
• Универсальный состав

Ваш исходный пример не требует ни одного и может быть легко сделан работать как так:

public interface IControlProvider<T>
    where T : Control, ISpecialControl
{
    T CreateControl();
}

public class SpecialTextBoxProvider : IControlProvider<SpecialTextBox>
{
    public SpecialTextBox CreateControl()
    {
        return new SpecialTextBox();
    }
}

На самом деле, учитывая, что большинство средств управления имеет общедоступного конструктора по умолчанию, можно сделать это еще легче:

public class ControlProvider : IControlProvider<T>
    where T : Control, ISpecialControl, new()
{
    public T CreateControl()
    {
        return new T();
    }
}

var control = ControlProvider<SpecialTextBox>.CreateControl();

Учитывая дополнительное ограничение на код вызова, не берущий ссылочную зависимость от SpecialTextBox непосредственно, это не будет работать.

Как насчет того, чтобы использовать интерфейсный состав?

Вы имеете

interface IA;
class B;

если это существует интерфейс использования для класса B, и сделайте составной объект

interface IB;
interface IAB : IA, IB;

измените класс

class C : B, IA

реализовать составной интерфейс (который не должен представлять проблему),

class C : B, IAB

И можно использовать интерфейс IAB в качестве типа ограничения.

Это - больше "ограниченных переменных", чем "ограниченные типы" - но определенно интересный. Как с универсальными ограничениями, существуют, вероятно, некоторые незначительные придираются с разрешением, если бы там конфликтуют участники, но те же обходные решения, по-видимому, применялись бы как с универсальными ограничениями.

Конечно, прагматическое представление состоит в том, что можно уже бросить и т.д., но затем необходимо сохранить эти две ссылки актуальными друг с другом...

хм... интересный.

Я не понимаю то, что Вы предлагаете, я думаю, что это - моя проблема.

Однако это звучит мне, поскольку Вы хотите возвратить управление, которое реализует определенный интерфейс.

Почему Вы не можете только сказать что возвраты метода что определенный интерфейс? Это звучит мне, поскольку Вы говорите, что "Я хочу возвратить классы, которые убывают от Управления, и это также реализует интерфейс ISomeInterface".

Возможно, решение состоит в том, чтобы извлечь части Управления, в котором Вы нуждаетесь в свой собственный интерфейс и указываете желание к эхо-сигналам той реализации оба?

Как это:

interface IControl { ... }
interface ISomeInterface { ... }

interface IControlInterface : IControl, ISomeInterface { ... }

Этот последний интерфейс указал бы необходимость в объекте, который реализует обоих основные интерфейсы, который является тем, что он кажется, что Вы хотите, за исключением того, что Вы хотите, чтобы одно из требований было базовым классом вместо интерфейса.

Я думаю, что можно решить это только при помощи интерфейсов.

Это существенно отличается от методы расширения ? Почему бы просто не расширить возможности управления?

edit: Ой, подождите, я не правильно прочитал, речь идет об ограничении его двумя типами, а не выбором двух типов. Я думаю, вы могли бы решить эту проблему аналогично классу, упомянутому ниже, хотя ...

Я однажды экспериментировал с классом, чтобы смоделировать это поведение:

public class Choice<T1, T2> 
{
    private readonly T1 value1;
    private readonly T2 value2;

    public Choice(T1 value)
    {
        value1 = value;
    }

    public Choice(T2 value) 
    {
        value2 = value;
    }

    public static implicit operator T1(Choice<T1, T2> choice) 
    {
        return choice.value1;   
    }

    public static implicit operator T2(Choice<T1, T2> choice) 
    {
        return choice.value2;   
    }

    public static implicit operator Choice<T1, T2>(T1 choice) 
    {
        return new Choice<T1, T2>(choice);
    }

    public static implicit operator Choice<T1, T2>(T2 choice) 
    {
        return new Choice<T1, T2>(choice);
    }

    public T1 Value1
    {
        get { return value1; }
    }

    public T2 Value2
    {
        get { return value2; }
    }
}

, который позволяет вам создавать такие конструкции:

[TestMethod]
public void TestChoice() 
{
    TestChoice("Hello");
    TestChoice(new []{"Hello","World"});
}

private static void TestChoice(Choice<string[], string> choice)
{
    string value = choice;
    string[] values = choice;

    if (value != null)
        Console.WriteLine("Single value passed in: " + value);

    if (values != null) {
        Console.WriteLine("Multiple values passed in ");
        foreach (string s in values)
            Console.WriteLine(s + ",");
    }
}

Обратная сторона неявные операторы заключаются в том, что он не выполняет неявное приведение к интерфейсу (он работает с приведением типов интерфейса), поэтому передача IEnumerable вместо строки [] не будет работать при попытке привести содержащееся значение обратно из Choice , T> в IEnumerable .

Обычно я предпочитаю просто используйте перегрузки / интерфейсы, кстати, так что не поймите меня неправильно: