Передача интерфейса вместо экземпляра объекта

Question

Возьмем, к примеру, метод SqlBulkCopy.WriteToServer ().Одна из перегрузок принимает IDataReader в качестве параметра.Мой вопрос: в чем выгода / преимущество передачи интерфейса методу вместо самого экземпляра объекта?

http://msdn.microsoft.com/en-us/library/434atets.aspx

Answer 1

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

Это также делает акцент на том, что действительно требуется для метода WriteToServer()- единственное, что требует его контракт, это чтобы вызывающая сторона передавала любой экземпляр конкретного класса, который предоставляет методы / свойства, объявленные интерфейсом IDataReader.

Answer 2

Передача интерфейса означает, что вы можете передать любой объект, который реализует этот интерфейс, а не только один конкретный объект.

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

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

Answer 3

Формальным типом параметра является тип интерфейса - это означает, что вы можете передать любой объект, который реализует этот интерфейс (или, скорее, экземпляр объекта, который реализует интерфейс).

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

Итак, если вашим источником данных является SQL Server, вы передадите SqlDataReader, если Oracle, OracleDataReader.

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

Это хорошо известный принцип проектирования - Программа для интерфейса, а не реализация .

А из MSDN - Когда использовать интерфейсы :

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

Answer 4

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

Пример:

interface IMyObject {
    public void SomeMethod();
}

public class MyObject : IMyObject {
    public void SomeMethod() {
        // implementing code here
    }
}

Теперь вы можете передавать любой экземпляр MyObject в качестве аргумента типа IMyObject :)

public class YourObject {
    public void DoSomething(IMyObject o) {
        // some code here
    }
}

YourObject yo = new YourObject();
MyObject   mo = new MyObject();
yo.DoSomething(mo); // works

Я надеюсь, что это имеет смысл!

Answer 5

На самом деле он ожидает, что вы передадите экземпляр типа, который реализует интерфейс, а не сам интерфейс.

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

Answer 6

Это одна из причин для интерфейсов - в этом примере все, что касается потребителя интерфейса (т. Е. Функции), это то, что он может читать данные - не имеет значения, является ли он из SqlDataReader илиOleDataReader или для любого другого поставщика - альтернативный поставщик будет предоставлять отдельные перегрузки, которые практически идентичны для каждого возможного устройства чтения данных (что, конечно, нецелесообразно, если кто-то может придумать его, например, для dBase или более экзотического механизма базы данных)