Почему я хотел бы использовать Интерфейсы? [закрытый]

В статье в моем блоге я кратко описываю три интерфейса целей, имеют.

Интерфейсы могут иметь различные цели:

• Обеспечивают различные реализации для той же цели. Типичным примером является список, который может иметь различные реализации для различных вариантов использования производительности (LinkedList, ArrayList, и т.д.).
• Позволяют модификацию критериев. Например, функция вида может принять интерфейс Comparable для обеспечения любого вида критериев сортировки, на основе того же алгоритма.
• Скрывают детали реализации. Это также помогает пользователю прочитать комментарии, с тех пор в теле интерфейса существуют только методы, поля и комментарии, никакие длинные блоки кода для пропуска.

Вот полный текст статьи: http://weblogs.manas.com.ar/ary/2007/11/

Я думаю, что необходимо добраться, польза понимают шаблонов разработки, так посмотрите там питание.

Выезд Главные Первые Шаблоны разработки

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

, Например:

public interface IExample
{
    void Foo();
}

public class Example : IExample
{
    // explicit implementation syntax
    void IExample.Foo() { ... }
}

/* Usage */
Example e = new Example();

e.Foo(); // error, Foo does not exist

((IExample)e).Foo(); // success

В .NET я создаю базовые классы и наследовался от них, когда классы так или иначе связаны. Например, Человек базового класса мог быть наследован Сотрудником и Клиентом. У человека могла бы быть общая собственность как поля адреса, имя, телефон, и т.д. У сотрудника могло бы быть его собственное свойство отдела. У клиента есть другая исключительная собственность.

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

Скажем, Вы хотите отслеживать набор материала. Упомянутые наборы должны поддерживать набор вещей, как добавление и удаление объектов и проверка, если объект находится в наборе.

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

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

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

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

, Кроме того, интерфейсы иногда используются в менее "чистых" целях. В Java они могут использоваться для эмуляции множественного наследования. В C++ можно использовать их для сокращения времени компиляции.

В целом, они уменьшают связь в Вашем коде. Это - хорошая вещь.

Ваш код может также быть легче протестировать этот путь.

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

Как Вы отметили, интерфейсы хороши для того, когда Вы хотите вынудить кого-то сделать его в определенном формате.

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

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

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

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

, Например, если Вы хотите записать алгоритм сортировки как quicksort, все, которое необходимо отсортировать любой список объектов, то, что Вы можете successfuuly сравнивать два из объектов. Если Вы создаете интерфейс, скажем ISortable, чем кто-либо, кто создает объекты, может реализовать интерфейс ISortable, и они могут использовать Ваш код банка.

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

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

Одним типичным примером является сменная архитектура. Разработчик записи, главное приложение, и хочет удостовериться, что все плагины, записанные разработчиком B, C и D, соответствуют тому, что его приложение ожидает их.

Интерфейсы являются формой полиморфизма. Пример:

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

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

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

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

Интерфейсы абсолютно необходимы в объектно-ориентированной системе, которая ожидает хорошо использовать полиморфизм.

классическим примером А мог бы быть IVehicle, который имеет Перемещение () метод. У Вас могли быть классы Автомобиль, Велосипед и Корпус, которые реализуют IVehicle. Они могут все Переместиться (), и Вы могли написать код, который не заботился, с каким механизмом он имел дело, именно так он может Переместиться ().

void MoveAVehicle(IVehicle vehicle)
{
    vehicle.Move();
}

Педали на автомобиле реализуют интерфейс. Я из США, где мы управляем на правой стороне дороги. Наши рули находятся на левой стороне автомобиля. Педали для механической коробки передач слева направо являются муфтой-> тормоз-> акселератор. Когда я перешел к Ирландии, управление инвертируется. Рули автомобилей справа, и они управляют на левой стороне дороги..., но педали, ах педали..., они реализовали тот же интерфейс... все три педали, были в том же порядке... поэтому, даже если класс отличался и сеть, что класс, управляемый на, отличался, я был все еще доволен интерфейсом педали. Мой мозг смог назвать мои мышцы на этом автомобиле точно так же, как любой автомобиль.

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

Интерфейсы определяют контракты , и это - ключевое слово.

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

Так, давайте посмотрим пример. Предположим, что у Вас есть метод, который обеспечивает функциональность для сортировки списка. Первая вещь.. что такое список? Вы действительно заботитесь о том, какие элементы делает это содержит для сортировки списка? Ваш ответ должен быть нет... В.NET (например), у Вас есть интерфейс под названием IList, который определяет операции, которые список ДОЛЖЕН поддерживать так, Вы не заботитесь о фактических деталях под поверхностью.

Назад к примеру, Вы действительно не знаете класс объектов в списке... ни один, о котором Вы заботитесь. Если можно просто сравнить объект, Вы могли бы также отсортировать их. Таким образом, Вы объявляете контракт:

interface IComparable
{
  // Return -1 if this is less than CompareWith
  // Return 0 if object are equal
  // Return 1 if CompareWith is less than this
  int Compare(object CompareWith);
}

, что контракт указывает, что метод, который принимает объект и возвращает интервал, должен быть реализован, чтобы быть сопоставимым. Теперь Вы определили контракт, и на данный момент на Вас не заботятся о самом объекте, но о контракт , таким образом, можно просто сделать:

IComparable comp1 = list.GetItem(i) as IComparable;

if (comp1.Compare(list.GetItem(i+1)) < 0)
  swapItem(list,i, i+1)

пз: Я знаю, что примеры немного наивны, но они - примеры...

Вообразите следующий основной интерфейс, который определяет основной механизм CRUD:

interface Storable {
    function create($data);
    function read($id);
    function update($data, $id);
    function delete($id);
}

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

Таким образом, у Вас могло теперь быть что-то как следующее:

class Logger {
    Storable storage;

    function Logger(Storable storage) {
        this.storage = storage;
    }

    function writeLogEntry() {
        this.storage.create("I am a log entry");
    }
}

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

следующий вопрос явиться результатом это затем, если базы данных и файлы CSV, и т.д., все могут хранить данные, разве они не должны быть наследованы от универсального Storable, возражают и таким образом покончили с потребностью в интерфейсах? Ответ на это не... не, каждое соединение с базой данных могло бы реализовать операции CRUD, и то же относится к каждому средству чтения файлов.

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