Как настроить «правило» интерфейса создания объектов в C #?

Question

Общее правило заключается в том, что я хочу сказать: «У T есть метод с параметром String, который возвращает List». Если говорить более подробно, мы могли бы вызвать интерфейс ICanCreateListOfObjectsFromString. Возможным приложением может быть поиск.

Такое чувство, что было бы неплохо иметь статический метод в моем интерфейсе, но я знаю, что это не разрешено в C #. Каков еще один подход для указания этого вида реализации контракта в классе?

Edit: Я хотел бы иметь следующий код:

public interface ISearch
{
    static List<T> Search<T>(String s);
}

public class MyObject : ISearch {
    List<MyObject> Search(string s) {
        //...
    }
}

public List<T> DoFooSearch<T:ISearch> () {
        return T.Search("Foo");
}

public List<T> DoBarSearch<T:ISearch> () {
        return T.Search("Bar");
}

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

Answer 1

Похоже, вы пытаетесь реализовать Mixin ... Что-то подобное существует в C # 3.0, и они называются "Методы расширения".

Что ты можешь сделать? Ну, они позволяют вам создавать функции, которые работают с указанными вами типами, и «добавлять» методы к ним. Поскольку этот тип может быть интерфейсом, это позволяет вам определять конкретные функции для интерфейса.

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

(Краткий поиск привел меня к Реализации миксинов с методами расширения C # .)

В качестве альтернативы: если вам не требуется множественное наследование для классов, реализующих ваш интерфейс, вы можете использовать абстрактные классы вместо интерфейсов и реализовывать конкретные функции непосредственно в них. Но опять же, это означает, что вы отказываетесь от наследования от чего-либо, кроме этого класса (и реализации других интерфейсов).

Answer 2

Первый вариант - разделить две проблемы:

• один тип для сущности
• один тип, чтобы быть фабрикой

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

Другой вариант - говорить в делегатах - то есть a Func<string,List<...>> (для некоторого типа списка); тогда вы можете создать делегата тривиально:

Func<string,List<...>> func = SomeType.SomeMethod; // static method

тогда вы можете передать func и (позже) использовать его как:

List<...> data = func("abc");

Answer 3

Может быть, фабричный шаблон - это то, что вы ищете.