Не можете указать статические методы как часть интерфейса?

Question

У меня есть набор объектов, которым я хочу соответствовать интерфейс, скажем, ISpecialObject. Однако, как часть моей реализации, я хочу инкапсулировать триггер создания этих специальных объектов в реализации каждого объекта ISpecialObject.

Так, например, у меня есть список типов классов, которые реализуют ISpecialObject, затем я хочу просмотреть каждый из них и вызвать статический метод, такой как CanCreate (некоторые данные), который сообщает мне, создавать ли экземпляр одного из это.

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

Может кто-нибудь предложить способ обойти это, или, альтернативно, лучший подход к решению проблемы инкапсуляции создания этих объектов? Я просто думаю, что все это неправильно.

Спасибо.

Редактировать: Возможно, я плохо сформулировал некоторые части этого. Я не хочу предоставлять реализацию в интерфейсе, а скорее указать, что она будет и что она будет статической. По сути, я хочу, чтобы объекты самоопределялись, позволяя объектам более высокого уровня запрашивать, когда их создавать во время выполнения.

Answer 1

Из того, что я понимаю, ваша основная проблема - создание набора объектов, которые соответствуют одному и тому же интерфейсу.Если это так, вы можете взглянуть на Factory Design Pattern , который является стандартным способом инкапсуляции такой логики.

Answer 2

.NET не допускает статических объявлений методов на интерфейсах. Они на самом деле не имеют смысла, так как все интерфейсы связаны с контрактом и полностью избегают реализации. Статические методы конкретно о реализации. Кроме того, методы интерфейса представляют собой вызовы виртуальных функций в зависимости от типа экземпляра, тогда как статические методы не зависят от экземпляра или даже класса (они могут быть назначены для любого конкретного типа).

Если у вас много реализаций ISpecialObject, вы можете использовать фабричный шаблон. Для этого вы должны определить интерфейс с именем ISpecialObjectFactory рядом с ISpecialObject:

class ISpecialObjectFactory
{
    ISpecialObject CreateInstance(...);
    bool CanCreate(...);
}

Каждый класс, который реализует ISpecialObject, должен иметь соответствующий ISpecialObjectFactory (например, UserObject также будет иметь UserObjectFactory). Для этого потребуется немного больше кода, но это общий шаблон, и я считаю, что он решит вашу проблему.

Answer 3

Мы только что обсуждали что-то очень похожее на это в другой теме. Методы расширения , безусловно, способ решить эту проблему.Они могут обеспечить реализацию для интерфейса, а методы могут рассматриваться как статические или использоваться как метод в экземпляре объекта, который расширяется.

Это не совсем дубликат в том смысле, как выВы сформулировали вопрос, но он дублирует по своей природе, поэтому проверьте ссылку ниже.

StackOverflow - свойство подкласса-реализовать-интерфейс-свойство-как-статическое

Answer 4

Я не вижу проблемы.Typename является просто префиксом при работе со статическими методами.Ничего не изменится, если статический метод живет где-то еще.

Тем не менее, посмотрите на методы расширения, которые, возможно, захотят, чтобы вы действительно этого хотели:)

Редактировать: Другойопция может использовать атрибуты.

Answer 5

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