Можно ли заставить класс .NET Framework реализовать интерфейс, который я определяю?

Question

Я хочу взять класс .NET (скажем, FileInfo для обсуждения) и заставить его реализовать мой интерфейс. Например:

public interface IDeletable
{
    void Delete();
}

Обратите внимание, что FileInfo ДОЛЖЕН иметь метод Delete (), поэтому этот интерфейс может иметь смысл.

Чтобы у меня был такой код:

FileInfo fileinfo = ...;
DeletObject(fileInfo);

public void DeleteObject(IDeletable deletable)
{
    deletable.Delete();
}

Можно ли сделать так, чтобы существующий класс соответствовал интерфейсу, подобному этому?

• Sean

Answer 1

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

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

Answer 2

Вы не можете, в основном. Не для Delete (поскольку он уже существует), но в целом: один вариант в C # 3.0 - это методы расширения:

public static void SomeMethod(this FileInfo file)
{ ... your code ... }

Теперь вы можете использовать:

FileInfo file = ...
file.SomeMethod();

Но здесь нет интерфейса.

Answer 3

Как сказал Нил Барнвелл, Адаптер - это путь. Но будьте осторожны, интерфейсы не должны использоваться таким образом, и, хотя это может пригодиться, вы должны хотя бы тщательно обдумать это.

Видите, интерфейс не является биективными функциями, они предназначены для предоставления набора «правил», определяющих, на что объект способен делать «да», но порядок, в котором они должны их использовать, заключается в том, чтобы сначала определить их для описания дизайн вашего приложения (или что-то, что вам нужно), а затем использовать его, а не наоборот. Или, другими словами, интерфейс определяет поведение в контексте ВАШЕГО приложения, которое может или не может конфликтовать с предполагаемым использованием .NET Framework.

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

Например, у меня может быть класс с методом Dispose ... это не обязательно означает, что он реализует IDisposable ... возможно, это не так, потому что мой метод Dispose может вызвать исключение или заблокировать на определенное время Таким образом, при выполнении контракта это не соответствует духу.

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