Интерфейсы в C #

Question

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

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

Я хотел бы знать, что они?Что они делают?Для чего я могу их использовать?

Answer 1

... сформулировано так, как программист мог бы понимать.

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

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

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

Еще один, который вы можете увидеть, это IDisposable. Это означает, что вы вызываете вызов .Dispose() для объекта, и он очистит ресурсы. Он ничего не говорит о том, какие ресурсы он будет очищать или что это за объект - это может быть StreamReader или SqlConnection или что-то в этом роде. Все, что он говорит, - это то, что у него есть метод с именем Dispose.

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

interface ICanPrintMyContents
{
    void PrintContents();
}

Затем группа классов, которые их реализовали:

class ParkingGarage : ICanPrintMyContents { ... }
class UnimpressivePolitician : ICanPrintMyContents { ... }
class BankingSimulation : ICanPrintMyContents { ... }

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

List<ICanPrintMyContents> list = { theGarage, insertNameHere, sim1, anotherGarage };
foreach(ICanPrintMyContents item in list)
    list.PrintContents();

(Примечание: соглашение о присвоении имен ICan... широко не используется, и я не советую его. Многим это не нравится, но я использую его здесь, потому что оно очень хорошо передает смысл интерфейса Более распространенным будет IPrintableContents или что-то)

Answer 2

Представьте, что у вас есть магазин пиццы (я краду этот пример из известной книги «Design Patterns»). Вы знаете, что все пиццы нужно заказывать, готовить, запекать и упаковывать в коробки. Ну, вы можете определить это общее поведение в интерфейсе:

public interface IPizza
{
   void Order();
   void Prepare();
   void Bake();
   void Box();
}

И пусть ваши разные пиццы реализуют этот интерфейс. При реализации интерфейса вы заставляете этот класс иметь те же методы и параметры, что и интерфейс, например:

public class PepperoniPizza : IPizza
{
   public void Order()
   {
       //Order Pepperoni pizza
   }

   public void Prepare()
   {
       //Prepare Pepperoni pizza
   }

   public void Bake()
   {
       //Bake Pepperoni pizza
   }

   public void Box()
   {
       //Box Pepperoni pizza
   }
}

У вас было бы то же самое с гавайской, сыром или любой другой пиццей.

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

Надеюсь, это поможет

Answer 3

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

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

public Interface IProductRepository
{
   public IList<Product> GetAllProducts()
}

Чем в вас Реализовать это с помощью некоторого класса, который возвращает жестко закодированные поддельные данные (для тестирования)

public class FakeProductRepository : IProductRepository
{
  public IList<Product> GetAllProducts()
  {
     // create some fake product list and return it
  }
}

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

  IProductRepository repository = new FakeProductRepository()

и проверь свою логику

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

Answer 4

Это просто контракт; в том смысле, что конкретный класс, который «реализует» интерфейс, должен иметь все те свойства и методы, которые определяет интерфейс. И в этих свойствах / методах вы можете написать любой код, но люди обычно пишут код, который делает определенные вещи.

Как например Возьмите концепцию сборки мусора: если вы хотите контролировать способ освобождения памяти вашим объектом, вы бы пошли на реализацию интерфейса IDisposable. Этот интерфейс предоставляет метод Dispose (). Хотя программисты пишут код для Dispose (), они никогда не вызывают его в коде. Фреймворк делает это за вас.

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

Сборка мусора - очень плотная тема. Но то, что я объяснил, только что поцарапало поверхность. Теперь, если вы действительно хотите увидеть интерфейсы в действии, попробуйте исследовать удаленное взаимодействие .net. Это еще одна плотная тема, но она поможет вам понять.

Answer 5

С обновлением Артуро Молина вот обновленные члены интерфейса

public interface IPizza
    {
       void Order();
       void Prepare();
       void Bake();
       void Box();
    }

ПРИМЕЧАНИЕ: Поскольку члены интерфейса по умолчанию общедоступны и не нужно упоминатьмодификаторы доступа явно также не будут принимать даже.

Answer 6

Я укажу вам предыдущий ответ, который концептуально описывает интерфейсы, используя аналогии: Почему мы используем Интерфейс?Это только для стандартизации?